Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design #2

Open
jancborchardt opened this issue Sep 25, 2013 · 2 comments
Open

Design #2

jancborchardt opened this issue Sep 25, 2013 · 2 comments

Comments

@jancborchardt
Copy link
Member

A more detailed design writeup. cc @jorin-vogel

Layout

  • time is linear, unlike month & week views in normal calendars, time just flows in one direction down
  • starts out anchored to today, but is endlessly scrollable down into the future and up into the past
  • time feedback on the events
  • snapping to full hours, days, weeks

Event creation flow

  1. clicking anywhere should prepare to create an event at that time
  2. an input box will be displayed at that height to put in the title
  3. pressing enter or clicking outside of the input box will create the event

Or you click & drag when it’s a longer event. Move around events as you wish.

Different calendars

  • calendars are represented as columns
  • on mobile:
    • compress to show just one column
    • other calendars are displayed thinner to the side still, for feedback
    • swiping could move between calendars
@jancborchardt
Copy link
Member Author

Other points I noted down some time:

  • shade weekend days (Saturday & Sunday for now) for easier orientation
  • in the future (when the days are bigger) maybe have a slight fade to darker for when it’s actually dark outside. An indicator at what time that event roughly is.
  • we could fetch the weather from some service and display that with an icon for each day
  • we could integrate an alarm function

@jancborchardt
Copy link
Member Author

More notes I found:

Current state & Problem

Different half-baked views: Calendars still use mostly paper-based metaphors. They are either 30 boxes for a month, 7 columns for a week, or all events thrown into a list for the agenda view. Sometimes there is a custom 4- or 2-week view which is very similar to the month view. A day view is a single-column segment of the week view with less information. Also, a month view is nothing more than four stacked week views.

Static blocks of time: As Marco Arment [marco.org post] describes in his article from 2010, the static nature of the month and week views make it mostly useless at the end of the month or week. Checking the calendar, events in the near future are the most relevant, and this relevance degrades with time. Events in the past however lose their relevance almost immediately after occurence.

Poor event grouping: People use different calendars, or rather event groups separated by purpose: One for private things, one for work or school, one shared with a friend, and maybe more. In current calendars, they are mostly just color-coded, and the events of the different purposes all mix together.

Long-time events vs. deadlines

Separate task lists: To-do lists are largely events without a specific time, but a specific order in which these tasks have to be carried out. The most important one – which has to be done next – is usually at the top.
Some calendars have a separate task list functionality, or affix that to the right of the other views, added like an afterthought.

Thoughts & Implementation

A better planning tool needs to:

  • focus on the immediate future
  • have a simple structure
  • be flexible

Time flows only down, past on top: Reading direction in English is primarily to the right and then down. While a left-to-right progress makes sense for time, most events are one-liners which would look off in that layout. Top-to-bottom time flow makes each event a line or block, and multiple events can easily be scanned like a list.

Focus on today & next few days, future days are smaller: Picking up the idea of the logarithmic calendar, the size of time blocks should decrease in the future, as their relevance decreases. Today will be the biggest day, followed by tomorrow, the day after tomorrow, and so forth. The seven days of the week after next are probably less relevant and thus smaller than all of today, as is the month after next and the year after next. A time unit should always at least be as big as the events contained it it though – so the sizing will adapt to your behavior by the number of events you have.

Different calendars are columns: Resizable

Focus on demand: With the height and width constraints, the calendar needs to be flexiblee and enable people to have a more detailed look when needed. For instance, it should be possible to focus on a specific calendar, which will then expand in size to fill almost the whole display width – still exposing the other columns to return to the normal view. Similarly, a time unit in the future can be focused on and will then expand to the display height.

Everything is an event

Click or drag anywhere to create a new event, snaps

Days are separated by light rather than by arbitrary lines at midnight

Notifications of important future events on the bottom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant