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:

larger image here

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Title: Toolbar enhancements » Move edit toggle, remove icons from toolbar

Retitled to be more specific. Toolbar enhancements could be virtually anything...

David_Rothstein’s picture

Subscribe.

"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"?

sun’s picture

Component: base system » toolbar.module
Category: feature » task
Priority: Normal » Critical
Issue tags: +D7 UX freeze

FINALLY.

This gets a full range of +1s from me.

moshe weitzman’s picture

I'm happier with this as well.

Bojhan’s picture

I 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.

xmacinfo’s picture

This 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.

Dries’s picture

Issue tags: +Favorite-of-Dries

Oh 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.

yoroy’s picture

What 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 :-)

Gábor Hojtsy’s picture

I'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.

sun’s picture

@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.

catch’s picture

This 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.

catch’s picture

Status: Active » Needs work
FileSize
2.28 KB

Patch 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.

David_Rothstein’s picture

I 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).

Gábor Hojtsy’s picture

Young 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.

Noyz’s picture

FileSize
474.69 KB

Yeah, 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

xmacinfo’s picture

Thank 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.

Noyz’s picture

FileSize
489.65 KB

960 with a long name is tough, but 1024 is doable.

Noyz’s picture

FileSize
513.94 KB

Same version as #17. Styled to better align with the existing Seven theme style.

Noyz’s picture

FileSize
513.94 KB

Same version as #17. Styled to better align with the existing Seven theme style.

xmacinfo’s picture

I 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.

Noyz’s picture

- Why trying to make shortcuts black? I prefer them white like in the above three examples.

Some 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.

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.

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.

- The vertical line between the Edit page button and "hello username" should be darker.

Perfectly ok with making it darker.

Bojhan’s picture

Oke, 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

David_Rothstein’s picture

That 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.

eojthebrave’s picture

Created 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.

mcrittenden’s picture

Subscribe.

yoroy’s picture

We should still reduce the height of the shortcut links:

current:

shortcuts-current

exploration:

reduceshotcutsheight

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

shortcuts-proposal

But lets start with this. We don't know if the similarity between the two rows of links is a problem at all.

Bojhan’s picture

Title: Move edit toggle, remove icons from toolbar » Adjust height of toolbar
moshe weitzman’s picture

I 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.

yoroy’s picture

Title: Adjust height of toolbar » Adjust height of shortcut bar
Status: Needs work » Needs review
FileSize
1.61 KB

patch makes it look like this in FF:

Welcome to d7 | d7

and like this in Safari, so needs work (maybe something with line-heights)

shortcuts-safari

so needs work, but letting bot review.

Dries’s picture

I agree that the height needs to be adjusted. Not sure it is critical though.

yoroy’s picture

Priority: Critical » Normal
FileSize
527 bytes

Not necessarily critical, but we really do want to fix it. Screen real estate prices are still quite high :)

shortcuts

Now looking fine in FF and Safari for me, please review.

Dries’s picture

I tested this patch but I don't see anything change, despite hard refreshes. Odd.

yoroy’s picture

Hmm, patch doesn't look correct indeed. Retry coming up

yoroy’s picture

FileSize
1.04 KB

How's this?

Dries’s picture

Status: Needs review » Fixed

Looks great. I committed this to CVS HEAD because it worked on my browsers. Hopefully that was the right thing to do.

Status: Fixed » Closed (fixed)
Issue tags: -Favorite-of-Dries, -D7 UX freeze

Automatically closed -- issue fixed for 2 weeks with no activity.