Cross linking from these issues:
#511286: D7UX: Implement customizable shortcuts
#473268: D7UX: Put edit links on everything
There's a general concern regarding the Edit shortcut not being available for users that turn off, or collapse the shortcut bar. Additionally there's a train of thought which suggests the edit link stands on its own (not as a shortcut). Last, another concern is the vertical size of the shortcut bar, coupled with the need for a custom icon for every added shortcut.
Here is a design that attempts to solve all of these problems:
Comment | File | Size | Author |
---|---|---|---|
#34 | smallershortcuts4.patch | 1.04 KB | yoroy |
#31 | smallershortcuts2.patch | 527 bytes | yoroy |
#29 | smallershortcuts.patch | 1.61 KB | yoroy |
#19 | toolbar2.png | 513.94 KB | Noyz |
#18 | toolbar2.png | 513.94 KB | Noyz |
Comments
Comment #1
Gábor HojtsyRetitled to be more specific. Toolbar enhancements could be virtually anything...
Comment #2
David_Rothstein CreditAttribution: David_Rothstein commentedSubscribe.
"Edit content" might not be general enough... with #473268: D7UX: Put edit links on everything it lets you edit lots of other stuff as well. Maybe "edit page"?
Comment #3
sunFINALLY.
This gets a full range of +1s from me.
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentedI'm happier with this as well.
Comment #5
Bojhan CreditAttribution: Bojhan commentedI am wondering, whether it really needed to go into an edit mode. And not have it behave like views ect?
Apart from that I have no real objections to this patch, we all knew from the start that getting icons was near to impossible unless Mark & Leisa stepped forward to do them. Because it didn't only require 3 default icons, it meant icons for the whole of Drupal + good standisation for contib.
What does trouble me with this patch, is that the shortcut bar looks more and more like a contextual links bar.
Comment #6
xmacinfoThis patch is a no go from my point of view. Small screens (1024 x 768) will not like this.
I would rather recommend that the Toolbar Module creates a status bar (a bit like the one created by the localization client) in which to display the "Edit" shortcut with variants like the active state. Other modules could use this status bar to load their own status or shortcuts.
We just must make sure not to use too much screen estate.
Comment #7
Dries CreditAttribution: Dries commentedOh behave, baby.
I'd probably name it 'Edit mode' instead of 'Edit content' because sometimes it is more about configuration than about editing? Just a thought.
Comment #8
yoroy CreditAttribution: yoroy commentedWhat I think xmacinfo worries about is if this all fits on 1024 width?
Is that a requirement? (I think so)
I like 'Edit page' better than 'Edit mode', it's easier to understand (regardless of if it's a page or not! :-)
Good proposal overall. Needs somebody to code it :-)
Comment #9
Gábor HojtsyI'm a bit worried about what happens to the menu items. The edit button now got this 3d look, but the rest of the buttons were not that shiny (in part to avoid some noise I'd assume). This could look very inconsistent when added with the non 3d buttons/shortcuts of the toolbar.
Comment #10
sun@Gábor: This is where I hope we shouldn't worry, and, trust the skills and experience of our designers to come up with a good looking and consistent solution.
Comment #11
catchThis is a duplicate of #510340: Remove icon placeholders from toolbar header., but has mockups and is more up-to-date, so marked that one instead. Obviously +1 from me.
Comment #12
catchPatch from there still applies though, re-rolled for fuzz/offset. Location of edit-in-place link needs to be handled when edit-in-place is in core, so this is just icon removal for now.
Before:
http://drupal.org/files/issues/missing_1.png
After:
http://drupal.org/files/issues/simplynotthere.png
Keeping CNW since this requires the png to be resized to make the shortcut bar shorter too.
Comment #13
David_Rothstein CreditAttribution: David_Rothstein commentedI think I share @Bojhan's concern about the top and bottom bars looking too similar to each other... seems like the shortcuts would at least need to be themed differently.
Whatever happened to the icons Young Hahn designed, months ago?
Also note that we wouldn't necessarily need an icon for every single possible shortcut to make it work, just a few for different categories... still don't know if it's out of the question, though. We have a pretty simple patch at #42493: Enable custom bullets/icons for specific menu items to at least get started on associating icons with admin categories in an organized way via the menu system, and allowing modules to hook in. It still needs love though (which I don't really have time to give it).
Comment #14
Gábor HojtsyYoung Hahn covered some of the core icons, but deliberately left out many. Also, he provides icons for some common contrib modules, but what we'd need are icon guidelines, templates for contributed modules to build icons. If you managed to maintain any modules which used icons (I did), you probably have noticed that when you try to extend into any direction, you need to go back to the one single person who did the icons and get him help again, or you are totally stuck. We could take whatever fine icons done by Young or others, but without a more holistic solution, we gonna depend on solely himself for the rest of Drupal iconography.
Comment #15
Noyz CreditAttribution: Noyz commentedYeah, Young's although beautiful wouldn't account for every shortcut. Additionally, icons need to be meaningful. If they're not, then they're just eye candy that requires a hunt-and-peck mode to try to get what you're after. It's my view, and was a view of Mark and Liesa's that there should not be an icon for everything. Acknowledging David's point in #13, I just don't think icons on shortcuts are necessary. I created it, named it, placed it. Why do I need an icon that may or may not be meaningful and increase the vertical size needed of the shortcut bar.
Re: shiny - I could make it look less shiny, but was trying to A) make it feel more prominent than shortcuts B) make the button stand out a bit more. I could rev if needed. The least of our concerns.
Updates to visual: includes a 1024 view (act 960), alternate treatment to shortcuts, and updated button text
Comment #16
xmacinfoThank you for creating a 960 version.
But please add the new 'Dashboard' menu link at the left of 'Content'. Also user names next to Hello can be longer.
I've enabled all modules and the new Dashboard modules adds a top-level link.
I agree with yoroy and make sure that supporting 1024 (960) window size is a requirement.
Comment #17
Noyz CreditAttribution: Noyz commented960 with a long name is tough, but 1024 is doable.
Comment #18
Noyz CreditAttribution: Noyz commentedSame version as #17. Styled to better align with the existing Seven theme style.
Comment #19
Noyz CreditAttribution: Noyz commentedSame version as #17. Styled to better align with the existing Seven theme style.
Comment #20
xmacinfoI love #19 (same as #18 ;-) )
It fits 1024 nicely and most usernames won't be longer than your example.
Some comments:
- Why trying to make shortcuts black? I prefer them white like in the above three examples.
- The active state of the Edit page button should display the text in light yellow, or blue, to differenciate the fact the it's not only a link, but a toggle button with two states, on or off. The rounded background is perfect since now it uses the same style as the rest of the tool bar.
- The vertical line between the Edit page button and "hello username" should be darker. The original design does not need that separator, but I understand why we might want one here. Making it darker will make it fit more with the design.
Comment #21
Noyz CreditAttribution: Noyz commentedSome were concerned with shortcuts looking the same as the main nav I used black as a way to differentiate. Consider them two options. White is more visible, clear and is the same link color as above - but suffers from feeling too close in nature to the primary. Black on the other hand is less visible, fails to follow the same link color pattern - but its more successful in that it differentiates primary from secondary better.
Actually had the same thought when designing these, but decided to hold off until I saw it working. The fact that it already has a differentiating background visual for active - may be enough.
Perfectly ok with making it darker.
Comment #22
Bojhan CreditAttribution: Bojhan commentedOke, we are going to do this - talked to Jeff Noyes about this and discssued in the #drupal-usability channel. The rationale is the following, we need to remove the icons - because the horizontal space it takes up is just to much. It shouldn't hurt the ascetics of this too much, nor should it impact usability to greatly.
I think we have one serious constraint, that keep us from doing icons.
1. Every module has to implement an icon, we don't want contrib to be required to make icons. It can quickly turn into a half-baked solution
Comment #23
David_Rothstein CreditAttribution: David_Rothstein commentedThat part, we already did - the icons have been gone for a while :)
Although some parts of the patch in #12 are probably still necessary to finish cleaning it up, and the styling/size of the shortcut bar isn't quite like the mockups yet....
The other part of this issue (possible "edit page" link in the top level of the toolbar) seems like it's better handled as part of #601150: Improved UI for contextual links now.
Comment #24
eojthebraveCreated a new issue to discuss implementation of an "Editing mode" since there was discussion both here, and in #601150: Improved UI for contextual links.
#648370: Implement a toggle for display of contextual links
Which points to this issue for discussion about what that editing mode toggle should look like.
Comment #25
mcrittenden CreditAttribution: mcrittenden commentedSubscribe.
Comment #26
yoroy CreditAttribution: yoroy commentedWe should still reduce the height of the shortcut links:
current:
exploration:
I'm actually really not sure the normal state should have a background box. I do notice that I want to make the normal state look different from the row of white links above.
proposal
But lets start with this. We don't know if the similarity between the two rows of links is a problem at all.
Comment #27
Bojhan CreditAttribution: Bojhan commentedComment #28
moshe weitzman CreditAttribution: moshe weitzman commentedI completely agree with reducing the height of the shortcut bar. I'd like it to be the same size as the static bar above it.
Comment #29
yoroy CreditAttribution: yoroy commentedpatch makes it look like this in FF:
and like this in Safari, so needs work (maybe something with line-heights)
so needs work, but letting bot review.
Comment #30
Dries CreditAttribution: Dries commentedI agree that the height needs to be adjusted. Not sure it is critical though.
Comment #31
yoroy CreditAttribution: yoroy commentedNot necessarily critical, but we really do want to fix it. Screen real estate prices are still quite high :)
Now looking fine in FF and Safari for me, please review.
Comment #32
Dries CreditAttribution: Dries commentedI tested this patch but I don't see anything change, despite hard refreshes. Odd.
Comment #33
yoroy CreditAttribution: yoroy commentedHmm, patch doesn't look correct indeed. Retry coming up
Comment #34
yoroy CreditAttribution: yoroy commentedHow's this?
Comment #35
Dries CreditAttribution: Dries commentedLooks great. I committed this to CVS HEAD because it worked on my browsers. Hopefully that was the right thing to do.