52
edits
(→Design: Add mockup M) |
(→Design: Add mockup N) |
||
Line 18: | Line 18: | ||
== Design == | == Design == | ||
We are currently seeking feedback on Mockup N. It is the result of a number of revisions (A through M) that are all documented below. The mockup images are intended as relatively rough "wire frames" to show layout and they only approximate spacing, sizing, and aesthetic details. Unless otherwise noted functionality is the same as in the current implementation. | |||
==== Mockup N ==== | |||
<gallery> | |||
File:Event-in-tab-mockup-n.svg|Mockup N | |||
</gallery> | |||
* "Responsive design" will be used for the implementation. As the window expands horizontally, the elements (and possibly horizontal spacing/margins) expand with it up to a breakpoint where the two-column “tab” layout goes into effect. Then the elements would continue to expand in both of the columns, up to a certain limit at which they would expand no further (to keep things more focused on a very wide monitor/window). After reaching that limit the elements would stay in place (left-aligned, or possibly center-aligned) as the window expands further to the right. | |||
* Shows new [https://docs.google.com/presentation/d/1TqvyE31vfNZ3KTlw1N2Ga8vy3I1WMVefMJEnkAlg9iA/edit#slide=id.p Mozilla date/time picker] (which may or may not be available yet at time of implementation). | |||
* Vertical scrolling in a tab: Categories, Reminders, Attachments, Attendees, and Description can take up as much vertical space as necessary to show all their items. In most cases, where there are only a small number of items, there will be enough room on the page to show them all without any scrolling. In less common cases where there are many items, the content of the tab will become taller than the viewport and the whole tab will become scrollable. (The toolbar at the top, with "Save and Close" etc., does not scroll but remains visible.) This approach allows viewing all of the items at once when there are many of them. (This is instead of having smaller boxes around each of these elements that are independently scrollable, which does not allow you to see all of them at once when there are many of them.) (This "whole tab scrolling" approach is how it works in Google Calendar.) | |||
* Vertical scrolling in a window: when the contents of the tabbed box (Reminders, Attachments, Attendees, and Description) becomes too big to fit vertically, the tabbed box becomes scrollable. | |||
* Suggestions are welcome for the name of the "More" tab in the window dialog design. | |||
==== Original Mockups A and B ==== | |||
The following two mockup images (A and B) and notes are based on the GSoC proposal and are a starting point for further refinements of the design. See below for subsequent mockups and notes. | The following two mockup images (A and B) and notes are based on the GSoC proposal and are a starting point for further refinements of the design. See below for subsequent mockups and notes. | ||
<gallery> | <gallery> | ||
File:Event-in-tab-mockup-a.svg| | File:Event-in-tab-mockup-a.svg|Mockup A | ||
File:Event-in-tab-mockup-b.svg| | File:Event-in-tab-mockup-b.svg|Mockup B | ||
</gallery> | </gallery> | ||
'''Basics''' | |||
The mockup images are intended as relatively rough "wire frames" to show layout and they only approximate spacing, sizing, and aesthetic details. | The mockup images are intended as relatively rough "wire frames" to show layout and they only approximate spacing, sizing, and aesthetic details. | ||
Line 34: | Line 51: | ||
There are two variants shown in two separate svg files. They differ only in the placement of the "privacy," "priority," "status," and "show time as" elements. | There are two variants shown in two separate svg files. They differ only in the placement of the "privacy," "priority," "status," and "show time as" elements. | ||
'''Event in a Tab''' | |||
The elements in the right-hand column are more optional, and in the simplest cases they will be left at their default settings. Putting them in the right-hand column gives greater prominence to the less optional elements in the left-hand column, like the timing of events, that must be entered for every event. | The elements in the right-hand column are more optional, and in the simplest cases they will be left at their default settings. Putting them in the right-hand column gives greater prominence to the less optional elements in the left-hand column, like the timing of events, that must be entered for every event. | ||
Line 56: | Line 73: | ||
A "Save" button has been added to the toolbar. | A "Save" button has been added to the toolbar. | ||
''' Event in a Window ''' | |||
"Add Reminder," "Add Attachment," and "Invite Attendees," are shown right above the box where these items will be listed when added/invited. The boxes containing these items are shown in a tabbed interface, much like the current implementation but with a "Reminders" tab added. A difference is that the respective tabs do not appear until they have content. When items are first added to them their tab is made the active tab. Ideally, as the window is resized the size of these boxes adjusts to match the height of the window. | "Add Reminder," "Add Attachment," and "Invite Attendees," are shown right above the box where these items will be listed when added/invited. The boxes containing these items are shown in a tabbed interface, much like the current implementation but with a "Reminders" tab added. A difference is that the respective tabs do not appear until they have content. When items are first added to them their tab is made the active tab. Ideally, as the window is resized the size of these boxes adjusts to match the height of the window. | ||
Line 62: | Line 79: | ||
As currently, the "Notify Attendees" and "Separate Invitation Per Attendee" checkboxes are only shown when the attendees tab is active. | As currently, the "Notify Attendees" and "Separate Invitation Per Attendee" checkboxes are only shown when the attendees tab is active. | ||
''' Toolbar Considerations ''' | |||
The toolbars shown in the mockup are simplified, without items like "Privacy" and "Invite Attendees" that can now be edited more directly "in place." The thinking behind this is to simplify things by keeping display and editing of elements together and not spread them out in different places. As shown, the toolbars only contain buttons that affect the event as a whole, like "save" and "delete." | The toolbars shown in the mockup are simplified, without items like "Privacy" and "Invite Attendees" that can now be edited more directly "in place." The thinking behind this is to simplify things by keeping display and editing of elements together and not spread them out in different places. As shown, the toolbars only contain buttons that affect the event as a whole, like "save" and "delete." | ||
Line 68: | Line 85: | ||
However, it may make sense, especially in the tab layout, to have more items in the toolbar to provide additional ways of editing elements for different users and use cases. If desired, we could keep the current toolbar items and potentially, in the tab view, add "Priority," Show Time As," and "Status" to the default set of toolbar items. There may even be additional items that could be added to the toolbar that go beyond the current toolbar options. | However, it may make sense, especially in the tab layout, to have more items in the toolbar to provide additional ways of editing elements for different users and use cases. If desired, we could keep the current toolbar items and potentially, in the tab view, add "Priority," Show Time As," and "Status" to the default set of toolbar items. There may even be additional items that could be added to the toolbar that go beyond the current toolbar options. | ||
''' Proposed Horizontal Resizing Behavior ''' | |||
As the window expands horizontally, the elements (and possibly horizontal spacing/margins) expand with it up to a breakpoint where the two-column “tab” layout goes into effect. Then the elements would continue to expand in both of the columns, up to a certain limit at which they would expand no further (to keep things more focused on a very wide monitor/window). After reaching that limit the elements would stay in place (left-aligned, or possibly center-aligned) as the window expands further to the right. | As the window expands horizontally, the elements (and possibly horizontal spacing/margins) expand with it up to a breakpoint where the two-column “tab” layout goes into effect. Then the elements would continue to expand in both of the columns, up to a certain limit at which they would expand no further (to keep things more focused on a very wide monitor/window). After reaching that limit the elements would stay in place (left-aligned, or possibly center-aligned) as the window expands further to the right. | ||
Line 74: | Line 91: | ||
As shown, the two-column layout rearranges the elements somewhat. This rearrangement is kept to a minimum for more consistency between the window and tab views. | As shown, the two-column layout rearranges the elements somewhat. This rearrangement is kept to a minimum for more consistency between the window and tab views. | ||
=== | === Mockups C - I === | ||
Mockups C through I are based on feedback from Richard Marti who suggested a full-width Description box, moving the Privacy etc. items below the Description, and rearranging Attachments, Attendees, and Reminders. | Mockups C through I are based on feedback from Richard Marti who suggested a full-width Description box, moving the Privacy etc. items below the Description, and rearranging Attachments, Attendees, and Reminders. | ||
Line 93: | Line 110: | ||
Mockup C | Mockup C | ||
* reminders in the right column in same row as timing info | * reminders in the right column in same row as timing info | ||
* attendees and attachments in the next row | * attendees and attachments in the next row |
edits