[Commits] (sheila) Edits to detail view spec.

[commits at osafoundation.org]

Commit by: sheila
Modified files:
docs/specs/rel0_6/Detailview-0.6.htm 1.2 1.3

Log message:
Edits to detail view spec.

ViewCVS links:
http://cvs.osafoundation.org/index.cgi/docs/specs/rel0_6/Detailview-0.6.htm.diff?r1=text&tr1=1.2&r2=text&tr2=1.3

Index: docs/specs/rel0_6/Detailview-0.6.htm
diff -u docs/specs/rel0_6/Detailview-0.6.htm:1.2 docs/specs/rel0_6/Detailview-0.6.htm:1.3
--- docs/specs/rel0_6/Detailview-0.6.htm:1.2	Tue Apr 26 10:08:25 2005
+++ docs/specs/rel0_6/Detailview-0.6.htm	Wed Apr 27 23:04:14 2005
@@ -26,7 +26,7 @@
       <td width="33%">Authors: <a
  href="mailto:sheila at osafoundation.org">Sheila Mooney</a></td>
       <td width="33%">Last edited:<!-- #BeginDate format:Am1a --> April
-26, 2005 10:00 AM - Version 1.2<!-- #EndDate --></td>
+27, 2005 11:00 PM - Version 1.3<!-- #EndDate --></td>
       <td width="33%">Creation date: April 20, 2005</td>
     </tr>
     <tr>
@@ -123,12 +123,14 @@
 <dl>
   <dt>Attribute Editor<br>
   </dt>
-  <dd> <br>
-  </dd>
-  <dt>"Edit in place" Field<br>
-  </dt>
-  <dd>This is a special type of field in the detail view where edit
-field is hidden until we click on the label for that field.<br>
+  <dt>Type-Over-Text Field</dt>
+  <dd>This is a special type of field in the detail view that appears
+as static text until you click on it. Type-over-text is used for fields
+that do not require a label in order for the user to understand them.
+There is also no need for hint text.</dd>
+  <dt>Regular Edit Field</dt>
+  <dd>These are non type-over-text fields that have a label and a text
+box.<br>
   </dd>
   <dt>Anytime Events</dt>
   <dd>These are event types unique to Chandler and are specified on a
@@ -153,11 +155,19 @@
 to that particular kind.</li>
 </ul>
 <p>Included below is a screen shot of the detail view targetted for
-0.6. This detail view represents an item stamped as an event, task and
-email. We have not included a separate image for each kind since the
+0.6. This specific detail view represents an item stamped as an event,
+task and
+email. Please Note: A new event would not include the from and to
+fields. We have not included a separate image for each Chandler kind
+since the
 only new visual feature work applies to event fields. Any formatting,
 fonts, layouts improvements should apply across all kinds.<br>
 </p>
+<p>The only 2 type-over-text fields we have in the detail view are the
+<b>Title</b> and the <b>Location</b> fields. All other text entry
+fields have a label
+and a text box with hint text.<br>
+</p>
 <p><br>
 <img alt="" src="ZeroSixDV_20050422.png"
  style="width: 903px; height: 649px;"><br>
@@ -197,7 +207,7 @@
 widest one); make the markup bar participate in labeling alignment</li>
   <li><b>Bug 2343:</b> We should have a larger font for the title in
 the detail view.</li>
-  <li>Make the location field and "edit in place" field.</li>
+  <li>Make the location field type-over-text field.</li>
   <li>Remove the border from around the entire detail view.</li>
   <li>No border around the markup bar; remove its background color.</li>
   <li><b>Bug 2688:</b>When no item is selected, DV should be white with
@@ -206,8 +216,6 @@
 fields, sample text fields and the dropdown items should all have the
 same fonts on a particular platform.</li>
 </ul>
-<p class="issue">[Sheila] Specify in more detail the characteristics of
-an edit-in-place field.</p>
 <h3>The Date and Time Fields</h3>
 <p>In the current version of Chandler, there is a single field for
 <b>starts</b> and for <b>duration</b>. Although these 2
@@ -271,8 +279,10 @@
 by
 specifying an end date later than the start date and leaving the time
 fields blank or in HH:MM format. The later 2 formats display in the
-Anytime are of the calendar, the former in D logenze format and the
-later in regular lozenge format.<br>
+Anytime are of the calendar. <br>
+  </li>
+  <li>Detailed visuals for all the different event types can be found
+in the calendar spec.<br>
   </li>
 </ul>
 <p>The behavior when setting the various date-time combinations is
@@ -309,8 +319,49 @@
   </li>
   <li>If you try and delete the start or end date, they get reset to
 today's date when you try and tab/click out of the field.</li>
-  <br>
 </ul>
+<h3>Field to Indicate Calendar Membership</h3>
+<p>A requirement has surfaced to have the detail view display which
+collection an item is a member of. We are specifically interested in
+this as it applies to calendar membership but the detail view would be
+generalized to support this for any item. Since we support items in
+more than one colection, we would have to have a way to display
+multiple membership. This gets a bit tricky since ideally we want to
+have a mechanism to edit what collections this item is part of via the
+detail view as well. Mimi has designed a way to handle this through a
+labelling feature but the full functionality is probably too ambitious
+for 0.6<br>
+</p>
+<p class="issue">[Sheila] Let's discuss this on Friday during the spec
+review. I realize there are quite a few unknowns here. We can look at
+some possible options and scope those. I will nail down the
+requirements for 0.6 ie: do we really have to be able to edit or is the
+display only ok? Does the All collection always get displayed in the
+list? Mitch and Sheila will be discussing this on Friday also.</p>
+<h3>Read Only and Editable Detail Views</h3>
+<p>Since we going to be able to subscribe to read only as well as read
+write calendars for 0.6, we need to support a read only detail view as
+well as the editable one we have today.<br>
+</p>
+<p>If a user subscribes to a calendar with read write permissions,
+there should be no changes in the user's ability to add, edit and
+update events. If the calendar is read only, we need to have a read
+only display for the detail view. The proposal is to have all fields
+and data display as static text. There should be a small icon at the
+top to the right of the markup bar that provides a visual cue to the
+user that this event is not editable.<br>
+</p>
+<p><img alt="" src="markup_bar_read_only.png"
+ style="width: 20px; height: 20px;"><br>
+</p>
+<p class="issue">Bryan, we are open to suggestions for the read only
+detail view. Ideally we want to prevent the user from editing so we
+don't have to popup the "read only" dialog. We should discuss this on
+Friday and put together a proposal. After the discussion, I will get
+Mimi to mock up a read only detail view based on your feedback. Apple
+iCal has a feature that only displays the detail view fields that are
+populated for read only events. This is a nice to have for 0.6 but I
+would like to keep it part of the discussion in case it's low cost.</p>
 <h3>Handling Recurring Events</h3>
 <p>For 0.6 we will be handling the display and creating of recurring
 events in Chandler. More specific details can be found in the 0.6
@@ -330,7 +381,23 @@
 </p>
 <p>If the user creates a new event using Chandler (in-place or using
 the menu item), the Custom option should not appear as an available
-selection in the recurrence dropdown.</p>
+selection in the recurrence dropdown. The default selection when
+creating a new event is <b>None</b>. If the user changes to drop down
+to
+"Weekly" a combo box appears below where the user can type in the
+format of <b>X times</b> for specifying a specific number of recurring
+events.
+If the user wants infinite recurrence, they can type in <b>None</b>.
+None
+should be the default that appears when the user selects a recurrence
+option.
+</p>
+<p class="issue">[Sheila] Bryan, we can iterate on this UI. Mimi
+thought you said it was easy to have this combo box with a format. The
+primary requirement is to give the user the ability to select something
+other than infinit recurrence but not have to go to a sophisticated
+custom date widget. I think there is value to let the user specify an
+"X times" recurring event. Let's discuss on Friday.</p>
 <p>If an event current has a Custom recurrence algorithm specified,
 they can modify this although they will only be able to select from the
 4 options available in Chandler. They will be prompted by a dialog when
@@ -393,9 +460,11 @@
 work for 0.6 that Jeffrey Harris is doing.</p>
 <p class="issue">[Sheila] It's possible that we may attempt to be more
 ambitious with timezones for 0.6 if we have time. We will revisit these
-requirements after the first integration point on May 30th. We need to
-understand the infrastructure work and scoping as well as dependencies
-on Jeffrey's schedule.<br>
+requirements after the first integration point on May 30th. I have an
+open task for Alec and Jeffrey to detail the architecture and work to
+support the kind of timezone scenarios we want to have in the app. Once
+that is scoped, we can better determine if we can support more UI
+features. I want to keep this as an open set of requirements for now.<br>
 </p>
 <h3>Sharing Detail View</h3>
 <p>TBD</p>
@@ -403,6 +472,15 @@
 <p class="issue">[Sheila] We are not specifying any changes to the
 sharing detail view at this time. We will revisit this after the first
 integration point on May 30th.</p>
+<h3>Alternate Detail View Position</h3>
+<p>One of the early 0.6 requirements was to have a menu item where the
+user could change the position of the detail view from the right to the
+bottom. Now that we are focussing on calendar events, it is not a high
+priority requirement to have this for 0.6. Due to the number of items
+on the calendar detail view we will only be able to see all the fields
+if it's positioned to the right. Until we have a scrollable detail
+view, the event view will not be very readable when positioned under
+the summary table view.</p>
 <h2>Code Design</h2>
 <p class="issue">[Sheila] We probably should have Bryan Stearns
 summarize the work involving attribute editors as well as notifications
@@ -445,6 +523,11 @@
       <td>April 26, 2005</td>
       <td>Second Draft - Modifications to date-time section</td>
     </tr>
+    <tr>
+      <td><a href="mailto:sheila at osafoundation.org">Sheila Mooney</a></td>
+      <td>April 27, 2005</td>
+      <td>Third Draft - Modifications based on Mitch and Mimi feedback</td>
+    </tr>
   </tbody>
 </table>
 </div>