Calendar:Event in a Tab

Revision as of 03:03, 13 May 2016 by Pmorris (talk | contribs) (Add svg images)

Please don't edit this page, unless you are Paul Morris (or maybe Fallen or MakeMyDay).

This page is for the "Event in a Tab" feature, a 2016 Google Summer of Code (GSoC) project by Paul Morris. It will document various details including design, implementation, etc. High-level progress updates will be posted to the Mozilla Calendar Project Blog (with the "gsoc" tag). The tracking bug is #1272540. Public communication channels are IRC (#calendar on irc.mozilla.org) and the mozilla.dev.apps.calendar newsgroup / mailing list.

GSoC Project Summary

Currently, events and tasks are created and edited in a dialog window. This project will add the option to create and edit them in a tab instead, providing more room and flexibility for the UI design. A supplemental goal is to explore implementing this feature in HTML/CSS/JavaScript rather than XUL. By using a responsive design, an HTML-based implementation could fully replace the current XUL-based event dialog. The UI could change depending on the width of the viewport, providing either a wider (tab) view or a narrower (dialog window) view.

Design

The following mockup images and notes are based on the GSoC proposal and are a starting point for potential further refinements of the design.

Basics

The mockup images are intended as relatively rough "wire frames" to show layout and they only approximate spacing, sizing, and aesthetic details.

The images show a newly created event and an event with elements added – repeat, reminders, attachments, attendees. These are shown in a tab and also in a the smaller window format. Unless otherwise noted functionality is the same as in the current implementation.

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.

For reminders, attachments, and attendees only a minimal UI is displayed at first until the user acts to add these items to an event. There is simply a link or button to click to add these elements. They are shown as a blue link in the mock-up but they could be a button instead.

For reminders, clicking the link/button creates a reminder, indicated by the appearance of two drop down menus, one for the kind of reminder and one for its timing, along with a small button (shown as an "[X]") to delete the reminder. Additional reminders can be added by clicking the "Add reminder" link/button.

A new selection box for choosing the timing of a reminder is shown at the bottom of the mockup images. Its behavior is similar to the time and date selection boxes. It replaces the current drop down menu and "custom" dialog.

Clicking the links/buttons to add attachments or to invite attendees shows their respective dialog boxes (which are the same as the current dialog boxes). A box with a list then appears showing the attachments and attendees, and these boxes work much same as the current boxes for these elements. The "Notify Attendees" and "Separate Invitation Per Attendee" checkboxes only appear when attendees have been invited.

A delete button (shown as an "[X]") has been added next to individual attachments and attendees, and a "Remove All" link/button has been added as well.

Privacy, priority, status, and "show time as" are indicated and changed via drop down menus, (rather than showing them in the status bar at the bottom of the window). This allows them to be edited "in place" and makes them more discoverable since they are currently only accessible via the options menu and so may be easily overlooked.

The labels such as "Title" are shown right-aligned for a clearer connection between them and what they label. But they could alternatively be left-aligned instead. There are no colons on these labels for the sake of visual simplicity.

To make time zone settings more discoverable, a link/button for "Time Zone" could be shown by default, as shown in the mockup images.

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.

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."

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 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.

Implementation

Possibilities to explore: