This forum is a place for people to discuss the design challenge around the 2.8 navigation and header that is posted about here: http://wordpress.org/development/2009/04/design-tweaks-whos-in-an-idea-in-three-acts/
Since discussion comments are not posted on the dev blog, this is a place to discuss the idea of community design, specific design ideas, file formats, whatever you would have left in the comments on that post.
Curious if you’re looking for a reworked PSD file, or a reworked wp-admin.css file? Or both? Or neither? 🙂
@johnjamesjacoby A reworked psd for the purpose of design selection. If the designer is also a competent coder and wants to code it up, that’d be great, if he/she can do it fast enough. Baseline, though, is a psd.
Comment about the concept:
Initially I didnt get why you want to move the header in a Singleblog-Installation… until I read, that you where talking about WordPress MU.
But in both cases, I dont think changing the header and navigation position is the right decision!
The header hierarchy is right: First comes the header with its quicklinks, then comes the navigation + content for all the blog-stuff that belongs to this header.
Changing this is a bad usability and iA desicion for all Singleblogs.
**For WordPress MU-Installation:**
Changing the navigation to solve the usability-problem of per-blog- and per-wordpress-mu-entries does not work! Even if the navigation is placed like in the new design. How does that help me to understand, which menu-entries belong to the currenct blog an which belong to the superiour level (MU)?
There ought to be another way.
For excample: Create a divider in the navigation that places MU-entries separate from blog-entries.
Or just move those menü-entries that belong to all blogs (to the MU level) inside the MU-Bar which is above the blog-bar, isnt it? (at least it is in buddypress).
So my vote is to leave it like it is until the overall problem is solved.
@tobias It may well be that a lot of people agree with you, and the existing nav structure wins the vote (we’ll include the current design as an option). With the number of people who’ve written posts about the nav since 2.7 came out, though, I don’t know. As I mentioned in the post, the chats were sampled, and that line about MU just happened to come before the point when Mark did a mockup.
The main reason to fiddle with the nav/header configuration has nothing to do with MU, it’s to get more of the nav bar above the fold. Because there are a lot of sections, there are people who get aggravated when the lower ones drop below the fold on their laptop screens. By moving the nav up a bit, these people could access their Settings section without having to scroll down.
Please believe me, after all the long nights working on the 2.7 interface, I’m not going to back any interface tweaks unless it seems like they will clearly improve the user experience
what about that: No quick-links (drop down) and no -moz-border-radius ,n Firefox. So WordPress admin menu faster in openings menus and drag and drops.
Pay attention top-right menu.
Sorry for my English.
@engin1984 For this design challenge, changing the functionality (which removing the quick links/favorites menu would do) isn’t an option, just changing the style. In addition to it being a popular feature with users, there are a number of plugins that use that menu.
Andrew has made a number of performance improvements in 2.8, which should make the admin faster. For the design challenge though, we’re only looking for visual design changes; removing existing functions isn’t being considered.
@janeforshort Thanks for your reply. Just to make it clear: You (all) did an amazing job with the new WP2.7 Interface. Its also great to see you thinking about improvements and involve the community in the decision-making!
The weekend is almost over. Nevertheless I’d like to point out a few issues with the backend menus when you have many plugins. I have almost 40 plugins installed and so the menu that pops up, when I hover the (minimized) settings icon, the list is so long that I cannot reach the first 4-5 items.
Also the items are not sorted by the item title but by something else. Sorting the items alphabetically would make the menu a lot better to read and easier to find what you are looking for. Now, when a new plug-in is installed it turns into a sub-menu search.
Also there should be some kind of visual seperation between WordPress items and plug-in items inside one menu (that goes in general for all menus).
If I had more time on my hands I’d try to submit ideas how to solve those issues.
To all of you out there, who solve issues and make WordPress better every day: THANK YOU! 🙂
@flashbytes Thanks for the feedback. We’re not really changing anything functional in the menus for 2.8 other than some new custom taxonomy hooks, I think, but I’ll bear your comments in mind when we start making the feature list for 2.9.
I hear you about the settings menu when you have a lot of plugins installed. I think the answer to that is ultimately to be found in standardizing where plugins place their configuration screens, which will be a tough one to agree on, much less enforce. Nevertheless, we would like to figure this out, and hope to work with the plugin community to determine the best approach. (First up, though, working with the community to determine the best ways to allow discussion and feedback on features in a less fragmented way than we have currently.)
As to visual separation between core WordPress menu items and plugin in menu items… I disagree. The idea of a plugin is that it becomes a seamlessly integrated part of your WordPress. It should feel like a part of the application, not like an add-on.
Thanks for taking hte time to comment with your experience, though. I hope when we start to address the issue of plugins and menus, you’ll make sure to get involved in the discussion.
Personally, not too worried about it. I like the Fluency design over the current option and its available as a plugin. More than that though, I prefer the dropdown menu provided by OZH. As long one of those options continues to be available. I don’t care what the dashboard in 2.9 looks like.
I have a lot of reservations regarding the DR* themes, partially for reasons mentioned by others either here or on the PollDaddy poll. Having the sub-menus fly out to right, rather than open up downward both covers up part of the screen (maybe not a huge deal), but also breaks the ability to leave a commonly used menu left open all the time. That alone should be a deal breaker.
Something I’ve not heard others talk about is the placement and style of the “Help”, “Screen Options”, Quick Links, etc. IK seems to be the only design that gets the place completely wrong, having the Quick Links below Help and Screen Options. Quick Links are global, so should absolutely be in the top menu. Screen Options and Help however are specific to the page you’re looking at, so should visually be within the context of the current page.
One of my other concerns with the DR* themes is the fact that Help and Screen Options had been changed from tabs to buttons. Tabs actually work out nicely in the current UI, because they slide down to reveal the additional content. What would the buttons actually do? How would you display the Screen Options? You certainly wouldn’t want to slide in like the current UI, they would be very inconsistent with a button. You could do a lightbox, but why take over the entire screen for things that should rightly be in a sidebar. Tabs definitely make sense.
Given the extraordinary time and effort Jane and the Automattic crew put in to developing Crazy Horse, it would be shame to make a drastic change to the UI without a similar level of scrutiny and attention. If the desire is to ship a UI change with 2.8 (given how little time is left), then it needs to make the least amount of changes possible to achieve the goal (which is to get more of the primary menu above the fold). Almost all of the proposed designed (especially those that are getting high votes) change far more than should really be necessary.
!!! the flyout menus will be terrible to use from mobile devices !!!
Flyout menus are usually also not very good for accessibility by screen readers or braille bars.
One suggestion for the future (before demolishing everything until 2.8 release date): make the interface greasemonkey-friendly, so people could use at least thick-client based scripting engines to adjust their layout…
Mobile access and accessibility are both key for me.
If anything, this ‘challenge’ will provide me both positives and negatives around Fluency which I can look to address in the future. Feedback is good 🙂
As long one of those options continues to be available.
The Fluency plugin will remain available, and will be updated regardless of the outcome of this challenge.
Having the sub-menus fly out to right, rather than open up downward both covers up part of the screen (maybe not a huge deal), but also breaks the ability to leave a commonly used menu left open all the time. That alone should be a deal breaker.
In defense of the flyouts, they are only there while your hovering over the menu, at which point you don’t really need to see what underneath because you should be looking at the menu. I believe the ability to leave a menu expanded is irrelevant if the menu is show on hover, but maybe that’s just me. “Deal breaker” might be a bit strong given that flyouts is how the current menu works when in ‘collapsed’ mode. My reasoning is here: http://deanjrobinson.com/wordpress/design-tweaks-28/
What would the buttons actually do? How would you display the Screen Options? You certainly wouldn’t want to slide in like the current UI, they would be very inconsistent with a button.
They would do something like this: http://www.flickr.com/photos/deanjrobinson/3101608647/ hard to demonstrate everything with a single screenshot
the flyout menus will be terrible to use from mobile devices
yes, agreed, however I doubt the current admin is particularly nice to use on a mobile device either. Theres a reason why there is a native iphone app and numerous “iphone optimised admin” plugins.
also worth saying that there is no reason that the Fluency design can’t have expand/contract style menus (like the current one) my mockups have flyouts simply because that what Fluency currently has.
Theres only so much you can knock together in a couple of hours, with additional time theres probably a bunch of things that I would/will change.
Keep the feedback rolling, keeps me thinking about ways I can possibly improve Fluency in the future.
- The topic ‘4/25 Weekend Design Challenge Comments’ is closed to new replies.