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! ;)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
