Priscilla Chung | 1 May 01:42 2007

Re: [cosmo][proposal][Bug 8398][Bug 6199] time zone drop down list on event details is confusing

My response in line: 

On Apr 30, 2007, at 11:19 AM, Sheila Mooney wrote:

Just a question. What's the relative priority of this?
Finishing up the time zone feature is a pretty high priority feature which to be completed for 0.7. It is probably more important then the dashboard. In addition we've already received d/f feedback about how confusing time zone is currently because in 0.6, time zone was only half completed. 

Why is it important that Cosmo handle the timezone list differently from the desktop.
The second proposal was not different from the desktop, nor is the proposal Bobby is making that different except for the names in the drop down list. This proposal is specific to address dogfood feedback we received from 0.6.  

If Bobby replies and says this is too difficult to implement for 0.7, then we can adjust the proposal and stage it so it matches the desktop—if that really is a more simplified proposal. 

As we discussed in our PPD meeting today, if no work is done to the time zone picker by preview,  it's not a huge loss and this is one of those items which is possible to punt post preview when we have to make some hard decisions and defer items post preview.

Does that make sense?
-Priscilla


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Mimi Yin | 1 May 02:23 2007

All Your Recurrence Rules Are Belong To Us...


After last Thursday's meeting, I started trying to wrap my head around all the various Recurrence Scenarios and came up with 3 lists:

1. What are all the different classes of changes users can/will make to recurring event series?

2. For each of the changes listed in list #1, what are all the different contextual factors that will affect the way the app behaves?

3. If you take each of the changes in list #1 and feed them through every combination and permutation of contextual factors in list #2, how does the app behave?

This will end up being quite a long write-up. I propose that we fill this in on an as needed basis. So who might need this write-up?

+ Cosmo Developers
- Is this the right framework for you? If not, how would you frame it?
- Are there certain areas that we should focus on first?

+ PPD
- This can help us check our design to make sure that we have a consistent user mental model.
- This can also help us prioritize recurrence features and bugs so that we know we're hitting the most common use cases first.

+ QA
- Might this help you in testing?
- Might some sort of PPD prioritization of scenarios help you prioritize what scenarios you test?

+ For FAQs and Release Notes?
- Is there anything that might be relevant to end-user documentation?

Questions:
+ What's missing from this list?
+ Where do implementation details fit in?

Mimi

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Priscilla Chung | 1 May 02:33 2007

Re: [Cosmo] Styleguide Notes + Follow-up

My response inline:

On Apr 27, 2007, at 7:27 PM, Mimi Yin wrote:

Thx for pulling this together Priss. I agree with all the items in your 3 buckets. I would add:

+ Collection pulldown and Collection details button into the 2nd bucket.
+ Login area links into the 2nd bucket
I respectfully disagree and would put this in the third bucket. Users looking for the collection drop down list and log in are already sold on cosmo and would already have an account. So maybe we're talking about different users for these buckets, those who already have an account and those who are coming to the hub for the first time. I'm focused on the new users—as you phrased it, 'CC's who don't know anything about Chandler.' 


Additionally, I wonder if there is a class of items that should pop a little bit more, even though they're technically things that people won't need unless they're looking for them...the reasoning being that these are things that users will be unfamiliar with, especially CC's who don't know anything about Chandler. This would include stuff like:

+ Mark-up bar buttons: Triage status and Stamping
+ Triage status in the Table
+ Week versus Day view selectors in the Calendar view (the way we do it is unconventional)
Well yes, the web app does not have a week vs. day view. Why should this be 'unconventional' on the desktop? Perhaps it would be better to be 'conventional' on the web app, because causal collaborators will not understand  'unconventional' approaches unless they see immediate, significant benefits. (This fell into no. three for me when I was using the desktop btw. and that was only because Jared had told me to click on the day of the week to see day view. Clearly he uses day view—I do not.)

+ Remove and Save buttons (again because we have a multi-pane layout, users may assume that you don't need to explicitly save changes).

So I guess what I'm saying is that I'm suggesting we have 2 tiers in the 2nd bucket.

1 Stuff users need to see immediately, whether or not they're looking

2A Stuff users need to trip over when trying to complete a task, because they may not know what it is exactly they should be looking for.
2B Stuff users need to be find easily when looking for them.
Both of these items are for users who need to find it when completing a task. If they are tripping over it, then we've not done our jobs and it fell into the third category.

3  Stuff users can find on their own time
This is all great for us, but honestly, I'm not convinced users will understand the subtleties you're trying to get across in no. two. Users either see a feature because it truly stands out against the 'grey' of the application or users will ignore it and only 'see' the feature in context of the activity. Adding these extra levels just adds more 'noise'. The third item is the 'Oh how neat, I never knew it did that!', which are the stuff users will discover on their own after using it after a while, or stuff we emphasize (and de-emphasize) in direct response to the user's action.



===

It may also be helpful to have a shared understanding of the various visual techniques available to us when it comes to implementing or applying the priorities we have set to the UI:

1. Location
+ Above the fold, below the fold
+ Top left corner
Top right corner, center? Highlighted very top of the application (alert bar) which will slightly overlap the app?
+ Dead center

2. Size

3. Saturation (ie. Grey text versus Black text)

4. Color and Brightness (ie. Bright green v. Dull grey)

5. Layering (ie. Overlay on top of UI, like a dialog)

6. Weight (ie. Line weight, Beveling, Drop shadows)

Does that sound reasonable?
Yes the last part sounds fine to me. Thx. -Priscilla


On Apr 27, 2007, at 6:18 PM, Priscilla Chung wrote:

Here is my list: http://wiki.osafoundation.org/Journal/OrderOfImportanceWebUI
-Priscilla

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Priscilla Chung | 1 May 02:41 2007

No design session tomorrow…

No excuses then on having your reviews in on time! ;)
-Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Andre Mueninghoff | 1 May 03:28 2007

Re: [Proposal] Punt the 'Never share' lock feature to Future

I have never used it while dogfooding, but I also have done little 
dogfooding of sharing with realistic scenarios that might prompt one to 
use the Never share feature. I've known its purpose, and have 
anticipated using it one day, but haven't yet.
Andre

Aparna Kadakia wrote:
> +1 for removing the icon. I have never used it while dogfooding the app.
>
> On Apr 27, 2007, at 7:44 AM, Mimi Yin wrote:
>
>> Morgen and I would like to propose punting the 'Never share' feature 
>> to Future. At this point, Morgen still needs to do extra work to 
>> model the lock feature in EIM (see fwd'ed thread below) and I'm not 
>> sure it's worth the trouble for Preview. 
>>
>> Has anyone used this feature while dogfooding? Can we easily remove 
>> the icon from the mark-up bar? Reid? 
>>
>> Mimi
>>
>> Begin forwarded message:
>>
>>> *From: *Morgen Sagen <morgen <at> osafoundation.org 
>>> <mailto:morgen <at> osafoundation.org>>
>>> *Date: *April 27, 2007 7:09:04 AM PDT
>>> *To: *Mimi Yin <mimi <at> osafoundation.org <mailto:mimi <at> osafoundation.org>>
>>> *Cc: *Sheila Mooney <sheila <at> osafoundation.org 
>>> <mailto:sheila <at> osafoundation.org>>
>>> *Subject: **Re: the lock button on the detail view*
>>>
>>> I am all for punting it for now if you don't think it's important.  
>>> Any little feature like this just adds to the complexity of things.
>>>
>>> On Apr 27, 2007, at 1:04 AM, Mimi Yin wrote:
>>>
>>>> So if this is at all a hassle to get right for Preview, should we 
>>>> consider punting it to Future?
>>>>
>>>> Lock means 'Never share'. Which is fine if you lock it before you 
>>>> share the item. But what happens if you lock it after the fact?
>>>>
>>>> Do we remove it from the server? What if you weren't the person to 
>>>> put it up there? I think we just stop syncing changes on that item, 
>>>> inbound or outbound, including deletes and removals by other people 
>>>> who have the item.
>>>>
>>>> Does that sound reasonable?
>>>>
>>>> Mimi
>>>>
>>>> On Apr 26, 2007, at 9:50 PM, Morgen Sagen wrote:
>>>>
>>>>> So I recently realized that I hadn't implemented anything related 
>>>>> to the "lock" icon in EIM based sharing.  But when I sat down to 
>>>>> work on it tonight, I wasn't actually sure what it should do.
>>>>>
>>>>> Does that lock mean inbound changes are not applied to the item?
>>>>>
>>>>> Does it mean no local changes for the item are sent to the server?
>>>>>
>>>>> If someone removes that item from the collection on the server, 
>>>>> does that affect what collections the "locked" item is in in your 
>>>>> Chandler?
>>>>>
>>>>> Thanks,
>>>>> ~morgen
>>>>
>>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>   

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Philippe Bossut | 1 May 06:52 2007

Re: Editing Read-only items

Hi,

Mimi Yin wrote:
> The new sharing framework has a neat new feature which allows users to 
> make local edits to read-only items. These local edits never get 
> synced back up to the server...and when server edits are pulled down 
> by the read-only subscriber, any conflicts with the user's local edits 
> are caught and presented to the user via our new conflict management UI.
>
> I'm concerned that this might cause some amount of confusion without:
> + Proper visual feedback: What are my local edit versus What's the 
> definitive server version
>
> + Some control over what can be edited: ie. I shouldn't be allowed to 
> change the date/time info on shared events, but adding private 
> annotations to the Notes field is fine.
IOW, a different styling for read-only non editable attributes...
>
> + Finally, as a user, I would expect that if I can have local edits on 
> read-only items, I should also be allowed to maintain local edits on 
> read-write items as well.
Yes but not on the same attribute or, how will Chandler make the 
difference between a change you want to share and one you don't want to 
share? This really begs for another feature (or features) : a way to 
annotate an item (e.g. add a sticky "don't forget to bring a cake!" to a 
read only event you subscribed to)  and/or a way to link an item to 
another (e.g. link a task "bring a cake" to the here above mentioned 
read only event) and see this link in the DV.
>
> Does anyone else have any opinions on this matter? Should we just try 
> it out in Preview and see what happens? Or should we wait to roll this 
> feature out after a little more design work has been done?
>
> How much work would it be to add functionality to implement UI code to 
> block edits on Read-only items?
I'm trying to get a sense of how read-only items do behave right now. 
Does anyone has a read-only ticket I could use for testing?

Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Philippe Bossut | 1 May 06:56 2007

Re: [Proposal] Punt the 'Never share' lock feature to Future

Hi,

Mimi Yin wrote:
> Morgen and I would like to propose punting the 'Never share' feature 
> to Future. At this point, Morgen still needs to do extra work to model 
> the lock feature in EIM (see fwd'ed thread below) and I'm not sure 
> it's worth the trouble for Preview. 
>
> Has anyone used this feature while dogfooding? Can we easily remove 
> the icon from the mark-up bar? Reid? 
>
Never used. I segregate the items I don't want to share in a collection 
that I don't share (or only "share with myself" i.e. I use the sharing 
feature as a publish feature...).

+1 to take off Preview if it simplifies things.

Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Priscilla Chung | 1 May 07:10 2007

Re: [Proposal] Punt the 'Never share' lock feature to Future


On Apr 27, 2007, at 7:44 AM, Mimi Yin wrote:

Morgen and I would like to propose punting the 'Never share' feature to Future. At this point, Morgen still needs to do extra work to model the lock feature in EIM (see fwd'ed thread below) and I'm not sure it's worth the trouble for Preview. 
+1

Has anyone used this feature while dogfooding?
Never used this feature for what it was intended for. 

Some d/f feedback Mimi—I always thought the lock meant the item is not editable and when I did try it once upon a time ago, I thought it just wasn't a working feature yet. I didn't realize it meant never share the item.

-Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Philippe Bossut | 1 May 07:24 2007

Re: Editing Read-only items

Philippe Bossut wrote:
> I'm trying to get a sense of how read-only items do behave right now. 
> Does anyone has a read-only ticket I could use for testing? 

Aparna gave me a ticket and I tried. So, for everyone's edification, you 
can edit anything in a read-only item. Apparently also the UI in the 
markup bar is broken and the striked crayon is not displayed.

So, right now, this is a rather confusing state of affairs for users 
indeed... We should at least repair the markup bar.

One proposal:
- if the item is "read-only", the markup bar shows a "striked crayon" icon
- nothing is editable when this icon is displayed but...
- ...the user can click the "striked crayon" to make the item editable, 
a dialog pops-up warning the user (edits will be local and conflict with 
edits coming from the server on sync) and the icon turns into a 
"non-striked crayon" (note that read-write item do not display any 
crayon of any kind so you can make the difference between a read-write 
item, a read-only item and a read-only but edited item...)

This seems to me the cheapest proposal for Preview (modifying the 
styling per attribute seems much riskier).

Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Jeffrey Harris | 1 May 09:31 2007

Re: Editing Read-only items

Hi Philippe,

> Aparna gave me a ticket and I tried. So, for everyone's edification, you
> can edit anything in a read-only item. Apparently also the UI in the
> markup bar is broken and the striked crayon is not displayed.

Intriguing.  I thought I'd just fixed the read-only markup-bar.  It
works if you try to subscribe to, say:

http://www.mozilla.org/projects/calendar/caldata/USHolidays.ics

It's possible read-only for EIM and ICS read-only aren't getting their
read-only details set in the same places, or perhaps you haven't updated
since Friday, or...  maybe it's working on Windows but not OS X?

It's true that at some point the code that was preventing read-only
items from being edited in the detail view seems to have lost a link.
It wouldn't be hard to get edit-prevention working again, I don't think.

Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design


Gmane