Sorry, would have added to SAK-17315 in JIRA, but not allowed
We're really glad to see this. The spec is well thought out and clear - Kristol, is this you?
Hopefully the following isn't an unsolicited comment. Megan's email asking for comments on 2.7 contributions might have been a simply yea/nay on including the feature, rather than detailed feedback. None of the following suggestions should delay release, but I have few suggestions about the location and display of print and close buttons.
Viewing all a user's messages appears to be, based on the greyed background around it, a modal window displaying in the browser page itself (aka "lightbox").
If you want this to look like a dialog box
1) The close buttons and links along the top:
Suggest this be implemented simply as a boxed "X." This should be quickly recognizable to both mac and windows users so probably doesn't need to be spelled out in text (though a rollover would be nice). I suspect those who use keyboard short cuts will already know about Esc.
2) the "Close" button at the bottom of the scrollable area:
a) Suggest this be moved flush right for two reasons. First, this seems to be the convention for both Mac and Windows users. Second, if the thread is long, the user's mouse will be scrolling at right, so their attention will be there. You may often see buttons flush left on web forms but that's because text and fields are left aligned; here, you read entire message left to right, so I don't think that thinking applies.
b) Suggest it is moved onto a non scrollable area at bottom. Not as critical, since the close button at top is never obscured, but ties to comment 3b below
3) The print button:
If this were the main screen of an app, or a sakai page, and were grouped with several other functions, left align feels correct. However, this is not really a main page - it is more like a dialog window or a print preview where there are limited actions to take place - in such cases, you generally have 1 or 2 buttons at the bottom of the window. Also, I feel like it's getting lost all by itself and it's placement in the same bar as the "close" (or "x") feels foreign - generally, print functions would be in another non-scrollable area above or below that bar.
a) Suggest move Print right, next to the Close button ("X") - this is still a little awkward, so ...
b) Suggest move Print down, into a non-scrollable area at bottom (see 2b above).
It's possible that the implementation varies from the spec, so I apologize if my comments have already been made irrelevant. I'm going to attach a diagram that is a visual representation of what I'm suggesting ("view 1 user UI suggestions.jpg").
Suggestion 1 is only 1, 2a, and 3a
Suggestion 2 is 1, 2b, and 3b
All other things being equal, I think Suggestion 2 is better, but 1 might be an incremental change.
There is 3rd suggestion - I have noticed, that there is an existing convention for printing in Forums already, for printing the thread - in that case, a new browser window pops up, and Print and Close are links at top, left aligned, as links in the page. However, that popup is triggered by a clicking a print icon and is more like a preview, whereas this is triggered by clicking a person's name, is simply a view. In other words, the differences seem reasonable - even within Microsoft Word, there are two versions of print preview, depending on where you access it from.
I'm sure whoever speced this thought about this much longer than the one afternoon I've given, and the deep thinking shows. Regardless of whether you can implement on your end, let me know if you think this a good idea, or if I'm ignoring other things that you've considered or other restrictions.
Keli Amann, User Experience Specialist
Stanford University