Last modified: 2014-10-17 18:42:37 UTC
Created attachment 11702 [details] Dropdown containing user tools links in page header We're currently overloading our page headers with user tools links and that's making it difficult to use that space for important links and notices (such as a link back to the Getting Started special page). I've built a simple mockup* (see attachment) to illustrate the idea. I'm sure this has been thought of before, but I think it's time to finally execute on it, or at least re-open this for discussion. It's currently styled under the assumption that we're reusing the Guiders extension to display popovers, but I'm open to changing it to look like a more traditional dropdown menu. Pros: * Frees up some much needed screen real-estate for important links * Makes user tools more scannable * Makes things look nicer on small resolutions. Cons: * Potential loss of feature discoverability * Information architecture not optimal; perhaps things like watchlist shouldn't be grouped with the user's talk page * _________________ (fill in the blanks) I suppose a valid no-JS/CSS3 fallback would be to display the links as they are now. * The omission of "Preferences" was accidental; I'll have to update the mockup later to reflect that.
Note about the attachment: I know that's where MoodBar is. It's not being suggested that we remove MoodBar; just illustrating the use/value of the header real estate.
(In reply to comment #0) > The omission of "Preferences" was accidental; I'll have to update the > mockup later to reflect that. Just to mention: Bug 41949 suggests to change the order of the items.
I assume this change is proposed for Vector (if not, please clarify). We should consider whether it would use core or Extension:Vector. Is it proposed as onmouseover or onclick? I would be skeptical of the latter, since it adds a click when visiting Profile/User Page, Watchlist, Contributions, and Sandbox. The first two are frequently used, the last (Sandbox) is being increasingly encouraged, and Contributions is often useful as a self-organizational tool. I think it would be okay to make Log Out and User Talk (this because it is exposed in other ways) less prominent. For mouseover, I think it's definitely worth considering. We could make it onclick/ontouch for touch-only devices, though I think they're increasingly using other interfaces. Or, touch-only could fall back to current. I don't think it should use GuidedTour for a few reasons: 1. From the user's point of view, it's totally different from both tooltips and a guided tour. So it shouldn't look the same. To even make it look like that mockup (basically just the Guiders arrows), we would have to special case several things, including the buttons and the X. 2. It would prevent us from putting it into core, and even Extension:Vector (unless Extension:Vector depended on GuidedTour which is not advisable). 2. It's architecturally confusing and problematic to use the extension for that. 4. There is currently not support for more than one simultaneous tour.
(In reply to comment #3) > I assume this change is proposed for Vector (if not, please clarify). We > should consider whether it would use core or Extension:Vector. I was thinking Vector, but if we want to redesign it to fit other themes that's fine by me. > Is it proposed as onmouseover or onclick? onmouseover. However, I should make a general point that "number of clicks" is no longer considered a valid measurement of usability and should be avoided in the future. >I think it would be okay to make Log Out and > User Talk (this because it is exposed in other ways) less prominent. Log Out is traditionally at the bottom of such menus, so I suggest we follow that pattern. In general, I'd like to minimize the number of items in that list, especially if we're including Preferences as well. > 1. From the user's point of view, it's totally different from both tooltips > and a guided tour. I'm cool with not using GuidedTour. However, the distinction between tooltips and guiders is more a developer's perspective and not a user's. No common user knows what a GuidedTour is. There are little windows with an arrow that pop over their content, point at something, and occasionally have buttons. Not sharing a common visual theme (like say, for example, the yellow MoodBar Tooltip) would cause someone to take notice. > So it shouldn't look the same. Off topic, but FYI: any popover we use in the future will probably use the same shadow, background color, border, and arrow such that all of our elements look consistent. Whether or not we use the GuidedTour extension for this, that's going to be the case for popovers. Put all of those ingredients together and you're going to have something that looks a lot like a Guider. It'll usually just have a different shape and size. > 2. It would prevent us from putting it into core, and even Extension:Vector > (unless Extension:Vector depended on GuidedTour which is not advisable). > 2. It's architecturally confusing and problematic to use the extension for > that. > 4. There is currently not support for more than one simultaneous tour. Good points, and agreed.
I would caution against onmouseover, as that's not very mobile friendly. There are still many, many people who use the desktop site on their mobile device.
Brandon, what do you think of my suggestion above to have it ontouch/onclick just for mobile?
Matthew: that sounds reasonable, if we can do sufficient and elegant device detection. I have some other thoughts: Shadows can be resource intensive in some mobile devices. Not so much an issue going forward, but it's there. We have to think about how Echo fits into this. The mockup doesn't account for it (and Echo has its own flyout styling, so these will need to be consolidated). This is also a change that should be opened to the community for discussion and input. I'd also suggest possibly running an A/B test to see the impact of the change on discoverability. This would be trivially done on usertesting.com.
It should be possible to reuse some of the device detection logic from MobileFrontend. They map to various device properties (DeviceDetection.php), though touch doesn't seem to be one, yet. I agree re A/B test and community input.
(In reply to comment #7) > We have to think about how Echo fits into this. The mockup doesn't account > for > it (and Echo has its own flyout styling, so these will need to be > consolidated). > Good point! I would like us to consider the fact that the un-collapsed personal tools menu has clearly reached capacity. Echo is key, and I would assume it'd live alongside this menu, not within in. > This is also a change that should be opened to the community for discussion > and > input. We don't need an RfC and consensus process to divine how this might impact current users. At least some of them are going to see this change, and notice the fact that it seems to add an extra click to access some of their most commonly-used items, and screws with their muscle memory. And they'd be correct. This is why Vector-only is probably a good idea, and we should consider the idea of the menu open action being sticky in some way, or at least providing that option with a control on the menu. > I'd also suggest possibly running an A/B test to see the impact of > the > change on discoverability. This would be trivially done on usertesting.com. usertesting.com is for remote usability testing. A controlled, randomized A/B test is not the same thing. I think a usability test of a prototype would be a valuable first step here, but that's different than an A/B split test.
> onmouseover. However, I should make a general point that "number of clicks" is > no longer considered a valid measurement of usability and should be avoided in > the future. I wasn't proposing it as a measurement, just noting it as a factor among others. If it were the only factor, every UI would be like the Million Dollar Homepage. :) > I'm cool with not using GuidedTour. However, the distinction between tooltips > and guiders is more a developer's perspective and not a user's. I was saying tooltip vs. drop-down menu and guided tour vs. drop-down, not tooltip vs. guider. From a general user perspective, a tooltip is where you hover to get a bit more information. A drop-down menu is where you click in a program like Word, or hover in some cases, to see a list of choices. I think there's a different feel. > Off topic, but FYI: any popover we use in the future will probably use the same > shadow, background color, border, and arrow such that all of our elements look > consistent. I agree consistency is good, identical may not be. Even your mockup is not identical, which is part of why I agree it's best not to use GuidedTour.
I'm going to take this bug and assign it to myself for now. We need to have a product discussion about this in a larger sense and until that happens we shouldn't implement this. I'll set up a meeting.
A consideration of who the interface is meant to serve would also be a good idea at this stage, I think. As it is, it feels like Monobook has become the skin of choice for editors (who need easier access to the watchlist and contributions links), while Vector has become the skin of choice for readers (mostly as it's the default).
MZMcBride, I'm not sure that's the case (Monobook vs. Vector). However, it should be relatively easy to study from the database (correlate skin use and active editing). Though we don't currently have data either way, I don't think this proposed change would make Vector worse for editors. There's a potential case that it makes it better by making things like Watchlist and Contributions that are too far right more accessible. If and when something is added to the upper right (e.g. Echo), we might want to consider placing this menu the left, which would move it (and thus the key features like Watchlist within) closer to the center of the screen.
The original vector design included grouping the user tools into a hover-to-open menu, but it got cut due to some negative feedback early on. I'm glad to see this is getting some attention now, because I've always felt it was a great way to reduce clutter - but at the same time I'm aware that it can be done wrong, and we need get it right because it's a very visible and frequently used feature. I believe we should do the following: 1. Run click-tracking (in monobook and vector) on the personal tools links and get a feel for how they are used and by who. If people who edit a lot use some of them frequently (as MZ has suggested) it will easy to confirm in the data. 2. Use the data we get, combined with some hallway user testing and our own brains to split the items into two levels of frequency of use. 3. Tuck the less-used items into a menu, leave the more frequently used items where they are. 4. Experiment with using icons for the most important items that aren't in the menu (a gear for preferences, a speech bubble or circle with number in it for notifications, etc.) 5. Consider bringing the search to the top line, rather than the 2nd line (making more room for tabs)
Created attachment 11711 [details] Apex Skin (concept) Here's an example of a skin design which uses a combination of a menu and top-level items in place of the personal tools.
Created attachment 11712 [details] Helix Skin (concept) Here's another example of a skin design which uses a combination of a menu and top-level items in place of the personal tools.
I don't think we need to bother goofing with monobook, tbh. My primary concern about this change is the discoverability of "Watchlist" and "Talk" for new users and making sure that we're aligned with the plans regarding Echo and Flow.
Given that we would have to go out of our way to exclude monobook from the stats, I think it's probably worth just getting those too, if only to put to rest any debate over whether the "real" editors have incompatible usage patterns (because if we only look at vector, it's easy to say we excluded people from the survey).
Oh! I didn't mean "not do the lookup on the stats" for monobook (and I quite agree with you re: "real" editors). I was saying that when/if we develop this, we probably don't need to do it for monobook.
I agree this bug should be limited to Vector. Someone can definitely propose doing it for Monobook separately, but that's a different matter. I've emailed the analytics list regarding the statistical correlation (skin v. active editor).
I'm not that worried about exposing Talk, since recipients will get a user talk notification (or later Echo). And they can still get to it at other times through User/Profile -> Talk
I've made this investigation official: https://gist.github.com/milimetric/5262726 I know some people might want to see this in gerrit, you're welcome to move it in there. It's just early in the morning and nobody's here to answer where it would go.
Ok, I've got a candidate solution. The fix to the query was the one I mentioned months ago but forgot about :) Step by step analysis: https://gist.github.com/milimetric/5262726 And results: /* +-------------+------------+ | skin | skin_users | +-------------+------------+ | | 2525 | | 0 | 32 | | chick | 21 | | cologneblue | 104 | | default | 26582 | | modern | 329 | | monobook | 2810 | | myskin | 8 | | nostalgia | 15 | | simple | 21 | | standard | 98 | | vector | 74 | +-------------+------------+ */
What are the empty 2525 at the top, more default/vector? It would be useful to coalesce all the vectors (default/vector/empty?) together for easier readability.
It sounds like everyone's happy with the validity of the results, closing the bug. (Feel free to re-open if you find a problem, but maybe ping me first if you can find me)
Oh, and it sounds like the 2525 will be the same as 'default' - assigned 'vector'
err - 'default' is assigned 'monobook' and I'm really sorry, I was posting in the wrong bug. I have learned that bugzilla does not reward hurried responses - no way to delete. Very sorry everyone!
This work is planning and in progress as a desktop web beta feature you can read more about the beta features planning here http://www.mediawiki.org/wiki/Lab_experiments
Almost one year of silence, resetting assignments. (In reply to Jared Zimmerman (WMF) from comment #28) > This work is planning and in progress as a desktop web beta feature you can > read more about the beta features planning here > http://www.mediawiki.org/wiki/Lab_experiments Moving to extension requests accordingly.
The code for this is being written by Juliusz inside MobileFrontend but they don't like desktop-related bugs from making that messy; the idea however is that this would be merged into Vector core, so moving back.
I can't imagine this happening in core. Surely not in Vector.
(In reply to Nemo from comment #31) > I can't imagine this happening in core. Surely not in Vector. The code by Juliusz is in VectorBeta extension, where it will likely remain as long as it's a Beta Feature. You can try it out now on Beta Labs (http://en.wikipedia.beta.wmflabs.org/).
(In reply to Steven Walling from comment #32) > (In reply to Nemo from comment #31) > > I can't imagine this happening in core. Surely not in Vector. > > The code by Juliusz is in VectorBeta extension, where it will likely remain > as long as it's a Beta Feature. You can try it out now on Beta Labs > (http://en.wikipedia.beta.wmflabs.org/). Sorry, *should be in*
(In reply to Nemo from comment #31) > I can't imagine this happening in core. Surely not in Vector. The limits of your imagination notwithstanding, the intent is to make changes for all users of all MediaWiki installs, so… yes.
Should we close this as a dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=44448 since that is the tracking bug for Compact Personal Bar (CPB) https://www.mediawiki.org/wiki/Compact_Personal_Bar
(In reply to Jared Zimmerman (WMF) from comment #35) > Should we close this as a dupe of > https://bugzilla.wikimedia.org/show_bug.cgi?id=44448 since that is the > tracking bug for Compact Personal Bar (CPB) > https://www.mediawiki.org/wiki/Compact_Personal_Bar I assume you mean bug 64321, not bug 44448.
Thanks. Thanks.
Bug 64321 is not the tracking bug for that feature.
(In reply to comment #38) (Sorry about the duplicate comment. This quirk is being discussed tangentially at bug 64864.)
