[Design] [cosmo] Styleguide updates

[Priscilla Chung]

Okay we're caught up on making this discussion public to the list.  
(whew!)

For those skimming the thread, these are just details Mimi and I are  
working though on the web UI. I'll summarize the decisions once we've  
settled on some of the design issues.

My reply inline. ;) We can follow up on Monday. Thanks!!! -Priscilla

On May 11, 2007, at 2:23 PM, Mimi Yin wrote:

> Let's walk through the workflows for when the tz and subscribe  
> pulldowns appear and disappear.
>
> 1. User clicks on ticket-URL to view share in ticket view:
> + User log in links are there.
> + Subscribe pulldown is there.
> + TZ may or may not be there depending on whether collection  
> contains tz data.
>
> 2. User subscribes to share and logs in.
> + User log in links are there.
> + Subscribe pulldown is no longer there.
> + TZ may or may not be there depending on whether collection  
> contains tz data and/or whether user turned on tz support in UI.
Ok I just realize something. If I may add to your work flows:

1. User clicks on ticket-URL to view share in ticket view:
+ Web UI defaults to dashboard view.
+ If there is time zone information, an alert bar will appear to turn  
on time zone settings.
+ User clicks to 'turn on time zone' in the alert bar.
+ Time zone drop down list will appear in calendar view.
+ If there is no time zone information in the shared collection, no  
alert bar will appear.
+ Subscribe pulldown is also visible in the header area in ticket view.

*Questions:*
+ How do we indicate to users that the time zone drop down list  
appears in the calendar view if they are default to the dashboard view.
+ Is it indicated in the instructions in the alert bar? This will be  
tough to do since the alert bar is rather small. Or maybe it's not  
important until the user switches to calendar view and it's there.
+ In the current time zone workflows, when the user 'turn on time  
zone', the 'settings dialog' appears for the user to set their time  
zone. The problem is, there are no settings in ticket view.
+ Do we still prompt the user with a dialog specific to time zones?  
Or does the drop down list just appear in calendar view (but the user  
will not see it appear until they switch to calendar view.)

2. User subscribes to share and logs in
+ Web UI defaults to dashboard
+ User logs in, links are visible.
+ Subscribe pulldown is no longer there.
+ Time zone drop down may or may not appear whether collection  
contains tz data and/or whether user turned on time zone support in  
the UI.


> Questions to think about:
> Should we optimize for the Logged-in view to look the  
> nicest? ...since that's probably the view that any one person will  
> spend the most time looking at.
I'm not sure about that statement. As pointed out, the compelling  
workflow currently is so CC do not have to sign up and log into their  
account. Using the bookmarkable ticket view had proven to be very  
handy for users with or without an account. I know Ted has pointed  
this out before on the list, even though BCM had pointed out for us  
not to do that, since anonymous users makes it hard to improve the  
web app with out tracking the users who have logged in.

I would think the *nicer* view should be the ticket view since those  
are the users you want to sign up for a hub account. Once again it's  
that balance of having users sign up, or allowing them to move the  
information out onto the desktop or other calendaring applications.

> If we do, I think we don't want the user log-in links to sit above  
> or below the TZ pulldown in the upper-right. It's kind of cramped.
Yes, I agree. I would rather see everything all on one line to give  
it more space.

> Do we want to try and keep UI elements relatively static, as in not  
> move them around between views?
> + Ticket view
> + Ticket view w/ tz
> + Logged in view
> + Logged in view w/ tz
>
> What about having it all in a line at the top of the screen? See  
> mock-up.
So I did another revision to the header now that it occurred to me  
that the time zone drop down list only appears in calendar view.

> + Ticket view:
> Subscribe with... | Sign up! | Log in | <TZ Pulldown> | Help
Subscribe with… | Sign up! | Help | Log in

> + Logged in view:
> Welcome username | Log out | Settings | <TZ Pulldown> | Help
Welcome username, Settings | Help | Log out
>
> <TZ Pulldown> is optional.
Since the time zone drop down list is specific to the calendar view,  
I reworked the layout, updated on the spec. I'm going to keep the  
'Log in/out' to the far right, since that is where 90% of the clicks  
are.

I realize a lot of web apps the 'Log in' links are usually at the  
very top right, but in your mock up when it was optically making the  
logo looked as if it's falling. It's that optical thing again where  
your eye tends to make things fall lower then the center.

FYI. Here's a reference online, but there are many design books that  
talk about these types of principals: 'The optical center of a  
rectangular region—the place where a viewer's eye spends most of its  
time—is slightly above the geometric center. (This is why mat board  
for photographs and artwork is usually slightly wider at the  
bottom.)' (http://www.math.duke.edu/education/ccp/resources/write/ 
design/graphic7.html)

> It will look even better when we can have custom pulldowns.
As we discussed, I guess we'll wait until Matthew has some time to  
investigate if user's can tab into a custom drop down list. If not we  
may need to evaluate the importance of getting to the drop down list  
for power users/accessibility. We'll table this discussion for future— 
I just wanted to point this out in case we need to refer back to this  
discussion.

>>> + Get rid of plus icon, replace with Add text underneath
>> Looks great. We'll probably need to make that text in the blue link.
>>
>
> Added in mock-up
>
>>> + Streamline NOW/LATER/DONE buttons
>> Excellent!
>>
>>> + Make buttons a middle-grey
>> Looks good. But when the button is in the down state, the gradient  
>> goes from top = dark, bottom = light. I can't tell in the view  
>> selector which one is the selected. Or are you saying in the view  
>> selector, the dashboard is actually in a 'normal' state, so it  
>> looks like it can be pushed?
>
> The Dashboard is selected.
Ok, I just turned it upside down so it's appears like the button  
state is down and selected.

>> If you were trying to just whip this up fast, then no big deal— 
>> send it out first and we'll fix the details in the final file. ;)
>>
>>> + Darker outline for RO (Rollover) effect
>> Looks good!
>>
>>> + Flatten out selected sort column header
>> I know we agreed to this, but I'm sorta indifferent to it  
>> currently. Maybe because it's over the triage states?  We'll leave  
>> it as it, it's just looking weird to me.
>
> Yea, I'm not crazy about it either. What about the blue in the mock- 
> up below? We can keep the active state flat.
The blue looks fine. We should reuse the bkg image in the calendar  
view as well to show 'today's date'—that was dogfood feedback bug:  
8402: https://bugzilla.osafoundation.org/show_bug.cgi?id=8402, making  
sure 'today' is more visually apparent. It's a low priority bug.
>
> I'd have to work out RO and MD states for active versus selected  
> though. So there'd be 6 states in all I think.
>
For the table headers? Normal, mouse over, mouse down and selected.  
Focus states are done in CSS, so no need to mock up the background  
image for that. Am I missing other states? Now that you have me  
thinking about the table headers, what do you think:
Normal: black text
MO: blue text, so users know they can click on it.
MD: dk blue text, perhaps light blue bkg, similar to buttons (we can  
test tweak as we go along)
Selected: rendered blue bkg., white text


>>> + Rework dialog
>> Looks good! In the style guide, it might be good to indicate  
>> exactly the position from the top left corner to the top left  
>> corner of the dialog—where it's position in the window. That all  
>> dialogs are positioned centered or a few pixels higher on the on  
>> the app., 'cause optically your eye will always make things look  
>> like it's not centered, even when it is.
>
> Sure.
>
>>
>>>
>>> Additionally, I've also tweaked the blue link and selection  
>>> highlight colors so that they're not so they don't compete with  
>>> the red dog as much...
>>
>> Ah, I meant to ask about this but didn't think about it till  
>> recently—the link color you chose, is it ok for color blind ppl? I  
>> realize this is a random issue since the app does not currently  
>> display visited links. You see, Bear had pegged me once, so you  
>> know…it's Bear! ;) In any case, picking a happy medium from a list  
>> here might be useful in case we need to show active vs. visited  
>> etc.: http://www.toledo-bend.com/colorblind/BlueChart.html
>
> Yes it's: #6699ff :D Thx for the link, that's handy to have.
>
>>>
>>> http://wiki.osafoundation.org/Journal/CosmoStyleGuide#LatestMockup
>>>
>>> I've also updated the Sign-up Workflow with the Instructions page.
>>> (I know the buttons and logo are all wrong, but I don't know that  
>>> it's worth fixing it for all the screens.)
>> No need to fix all the screens, but we may want to fix the  
>> activation page I mocked up—if you want the logo on the top left  
>> or centered. The button will be standard w/ the existing button  
>> templates you did.
>>
>> http://wiki.osafoundation.org/Journal/ 
>> SignUpForAnAccountForOtherCalendaringClients#GatewayPage
>
> Oh, I re-styled that page on the Sign-up Workflow page, did you see?
Yes I can see the mock up now w/ the updated file. Probably just need  
to fix small details such as adding the new logo to the page, making  
the button more consistent w/ the current buttons on the web UI. I  
like the green to 'go enter the hub now!' Why don't you just reuse  
the 'Now' triage button style? It will be easier in the end to just  
use for the page instead of adding new button graphics.

I know I added an arrow in the button I created in the sketch, but  
I'm thinking the icon you're using is the same desktop icon as this  
collection is published on the server. Maybe we should just leave out  
the arrow for now.

>>> http://wiki.osafoundation.org/Journal/CosmoSignUpWorkflow
>> + user types in 'http://hub.chandlerproject.org
>> + probably don't need the 'for one' text, sign up is fine.
>> + #2 sign up dialog which overlaps the login
>> + Last step, user is not taken to log in page, but is logged in  
>> automatically after email verification (I hope, that's what I spec- 
>> ed out). =)
>>
>>> Questions:
>>> + Do we need a Mousedown state?
>> Yes. See file I had sent earlier.
>
> Okay I'm not sure I understand it completely. We can go over it  
> together?
>
Yup. Basically I just need the bkg image to test with.

>>
>>> + Do we want to do a copy review and make sure we're using  
>>> consistent language across both Hub and Desktop?
>> Yes!!!!!
>
> Okay, can you pull together all the copy that's in the UI? I had  
> started a thread with mde a while ago about error dialogs? Here's  
> the thread: http://lists.osafoundation.org/pipermail/design/2007- 
> January/006152.html
Sure. I had on my list to gather the error messages and pull together  
some consistent text for messages. Hmmm…maybe I should be sharing  
this list of todos with you w/ Chandler! ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070512/e14846c9/attachment.htm