I made this today:
http://unicorn.wmflabs.org/staticheader/
It could use some work (I hard-set the searchbox width on movement, and it should probably flow to fill all available space).
But it gives an idea of what the experience would be like.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Sat, May 18, 2013 at 3:27 PM, Brandon Harris bharris@wikimedia.orgwrote:
I made this today: http://unicorn.wmflabs.org/staticheader/ It could use some work (I hard-set the searchbox width onmovement, and it should probably flow to fill all available space).
But it gives an idea of what the experience would be like.
Very nice.
Key consideration: how would this interact with the fixed toolbar of VisualEditor?
Great mockup Brandon,
few notes
1. A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny 2. just played around with the visual editor fixed header. I think that we might be able to handle the visual design of VE slightly differently (skin change?) to further differentiate it from the fixed header or vice versa. In an edit mode having two fixed headers might not be the end of the world…it might, who knows? 3. search FREAKS out on browser resize, and scroll on mobile. 4. Having search in-line with the rest of the profile bar(?) further highlights the issue that there is too much going on there, see point 1.B 5. Some easing/animation might help, when you scroll quickly some weird flashing/bouncing happens that is disconcerting, and makes me cringe a bit. 6. All in all, really cool, and I appreciate you taking the initiative to mock this up.
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Sat, May 18, 2013 at 7:21 PM, Steven Walling swalling@wikimedia.orgwrote:
On Sat, May 18, 2013 at 3:27 PM, Brandon Harris bharris@wikimedia.orgwrote:
I made this today: http://unicorn.wmflabs.org/staticheader/ It could use some work (I hard-set the searchbox width onmovement, and it should probably flow to fill all available space).
But it gives an idea of what the experience would be like.Very nice.
Key consideration: how would this interact with the fixed toolbar of VisualEditor?
-- Steven Walling https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Pretty nice, but...
On Sun, 19 May 2013 09:07:30 +0200, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
This. In my opinion mving the location of search and logo on scroll means that at least one of the designs - the "basic" one we have right now, or the scrolling one - is horribly broken.
Also, why is the personal menu kept on scrolling instead of the article tabs? Is it considered more important now?
Replying to all comments, in line.
This is an interesting exercise because it brings (back) up some flaws with our current information architecture. I'll get into that at the bottom.
On May 18, 2013, at 7:21 PM, Steven Walling swalling@wikimedia.org wrote:
Key consideration: how would this interact with the fixed toolbar of VisualEditor?
I should expect that the VE's toolbar would dock just below the user toolbar.
On May 19, 2013, at 12:07 AM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Great mockup Brandon,
few notes • A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
Yes, I agree. This came out of our conversation the other day about reducing the number of possible search fields that may exist on a page and having them perform multiple duties. I'm not happy with the current behavior.
There are a couple other ways to solve for this that come to mind immediately, but they all have flaws of some kind or another:
1) Leave the search at the same vertical point and hiding the tabs on scroll, increasing the width of the search. - This increases the vertical size of the docked toolbar (creates problems with the existing event with the logo branding, but nbd) - There's interaction issues with "when should the tabs disappear)
2) Collapse the user tools to an icon or two (so that the Echo notifications are still visible) and make the transition of the search box more elegant
3) Move the tabs (see below)
• just played around with the visual editor fixed header. I think that we might be able to handle the visual design of VE slightly differently (skin change?) to further differentiate it from the fixed header or vice versa. In an edit mode having two fixed headers might not be the end of the world…it might, who knows?
It is my fervent hope that "edit" mode manages to eliminate a lot of controls on the page that I don't think need to be there. Search, for example, doesn't make a lot of sense to me in edit mode.
• search FREAKS out on browser resize, and scroll on mobile.
Prototype. If you go through the underlying html and css, it's very hackey.
• Having search in-line with the rest of the profile bar(?) further highlights the issue that there is too much going on there, see point 1.B • Some easing/animation might help, when you scroll quickly some weird flashing/bouncing happens that is disconcerting, and makes me cringe a bit.
I'm using a library called "waypoints". It's possible for us to hook animations into it (when element X arrives at scroll position Y, activate animation Z) but I wasn't so much concerned with that.
On May 19, 2013, at 1:47 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sun, 19 May 2013 09:07:30 +0200, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
This. In my opinion mving the location of search and logo on scroll means that at least one of the designs - the "basic" one we have right now, or the scrolling one - is horribly broken.
I think both, and I'll explain why below.
Also, why is the personal menu kept on scrolling instead of the article tabs? Is it considered more important now?
Yes, if only for access to the Echo badge. In the future, there may also be other important things that show up there that may need permanence but Echo is the primary use case right now.
On to what I think are the main navigation problems.
It is my humble opinion that the primary issue we have is the tabs. I've got a couple reasons why I don't think they work the best, but the primary one is this:
They are not directly tied to the content that they control.
In the Vector design, the user is trained to understand that "things inside the blue line" are content, while what is outside of that is "chrome". Further problematic is mixing *content* actions within *site* actions (via the sidebar).
Moving the various tab functions inside of div.#content, perhaps directly under the article title, will tightly bind them to the content.
(I also don't think they should be tabs. We break our metaphor when we have *two* active tabs at any one time.)
This then leaves us plenty of space in the top for all sorts of fun stuff - like making the search box full width.
I can probably throw something together to illustrate this without much effort.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Brandon this is good stuff! Maybe we need a group whiteboard session to address a few legitimate concerns and post an updated prototype to the media wiki page?
On Sun, May 19, 2013 at 12:26 PM, Brandon Harris bharris@wikimedia.orgwrote:
Replying to all comments, in line. This is an interesting exercise because it brings (back) up someflaws with our current information architecture. I'll get into that at the bottom.
On May 18, 2013, at 7:21 PM, Steven Walling swalling@wikimedia.org wrote:
Key consideration: how would this interact with the fixed toolbar of
VisualEditor?
I should expect that the VE's toolbar would dock just below theuser toolbar.
On May 19, 2013, at 12:07 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Great mockup Brandon,
few notes • A.search box moving location feels weird, B.I can see this
change being part of a a header reorg in general but having search changing position on scroll feels a little funny
Yes, I agree. This came out of our conversation the other dayabout reducing the number of possible search fields that may exist on a page and having them perform multiple duties. I'm not happy with the current behavior.
There are a couple other ways to solve for this that come to mindimmediately, but they all have flaws of some kind or another:
1) Leave the search at the same vertical point and hidingthe tabs on scroll, increasing the width of the search. - This increases the vertical size of the docked toolbar (creates problems with the existing event with the logo branding, but nbd) - There's interaction issues with "when should the tabs disappear)
2) Collapse the user tools to an icon or two (so that theEcho notifications are still visible) and make the transition of the search box more elegant
3) Move the tabs (see below)• just played around with the visual editor fixed header. I thinkthat we might be able to handle the visual design of VE slightly differently (skin change?) to further differentiate it from the fixed header or vice versa. In an edit mode having two fixed headers might not be the end of the world…it might, who knows?
It is my fervent hope that "edit" mode manages to eliminate a lotof controls on the page that I don't think need to be there. Search, for example, doesn't make a lot of sense to me in edit mode.
• search FREAKS out on browser resize, and scroll on mobile.Prototype. If you go through the underlying html and css, it'svery hackey.
• Having search in-line with the rest of the profile bar(?)further highlights the issue that there is too much going on there, see point 1.B
• Some easing/animation might help, when you scroll quickly someweird flashing/bouncing happens that is disconcerting, and makes me cringe a bit.
I'm using a library called "waypoints". It's possible for us tohook animations into it (when element X arrives at scroll position Y, activate animation Z) but I wasn't so much concerned with that.
On May 19, 2013, at 1:47 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sun, 19 May 2013 09:07:30 +0200, Jared Zimmerman <
jared.zimmerman@wikimedia.org> wrote:
A.search box moving location feels weird, B.I can see this change being
part of a a header reorg in general but having search changing position on scroll feels a little funny
This. In my opinion mving the location of search and logo on scroll
means that at least one of the designs - the "basic" one we have right now, or the scrolling one - is horribly broken.
I think both, and I'll explain why below.Also, why is the personal menu kept on scrolling instead of the article
tabs? Is it considered more important now?
Yes, if only for access to the Echo badge. In the future, theremay also be other important things that show up there that may need permanence but Echo is the primary use case right now.
On to what I think are the main navigation problems. It is my humble opinion that the primary issue we have is thetabs. I've got a couple reasons why I don't think they work the best, but the primary one is this:
They are not directly tied to the content that theycontrol.
In the Vector design, the user is trained to understand that"things inside the blue line" are content, while what is outside of that is "chrome". Further problematic is mixing *content* actions within *site* actions (via the sidebar).
Moving the various tab functions inside of div.#content, perhapsdirectly under the article title, will tightly bind them to the content.
(I also don't think they should be tabs. We break our metaphorwhen we have *two* active tabs at any one time.)
This then leaves us plenty of space in the top for all sorts offun stuff - like making the search box full width.
I can probably throw something together to illustrate this withoutmuch effort.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I'm sort of goofing around with an alternative thought right now; it may be better to wait until after that's done and we can talk about everything together.
On May 20, 2013, at 12:57 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Brandon this is good stuff! Maybe we need a group whiteboard session to address a few legitimate concerns and post an updated prototype to the media wiki page?
On Sun, May 19, 2013 at 12:26 PM, Brandon Harris bharris@wikimedia.org wrote:
Replying to all comments, in line. This is an interesting exercise because it brings (back) up some flaws with our current information architecture. I'll get into that at the bottom.On May 18, 2013, at 7:21 PM, Steven Walling swalling@wikimedia.org wrote:
Key consideration: how would this interact with the fixed toolbar of VisualEditor?
I should expect that the VE's toolbar would dock just below the user toolbar.On May 19, 2013, at 12:07 AM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Great mockup Brandon,
few notes • A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
Yes, I agree. This came out of our conversation the other day about reducing the number of possible search fields that may exist on a page and having them perform multiple duties. I'm not happy with the current behavior. There are a couple other ways to solve for this that come to mind immediately, but they all have flaws of some kind or another: 1) Leave the search at the same vertical point and hiding the tabs on scroll, increasing the width of the search. - This increases the vertical size of the docked toolbar (creates problems with the existing event with the logo branding, but nbd) - There's interaction issues with "when should the tabs disappear) 2) Collapse the user tools to an icon or two (so that the Echo notifications are still visible) and make the transition of the search box more elegant 3) Move the tabs (see below)• just played around with the visual editor fixed header. I think that we might be able to handle the visual design of VE slightly differently (skin change?) to further differentiate it from the fixed header or vice versa. In an edit mode having two fixed headers might not be the end of the world…it might, who knows?It is my fervent hope that "edit" mode manages to eliminate a lot of controls on the page that I don't think need to be there. Search, for example, doesn't make a lot of sense to me in edit mode.• search FREAKS out on browser resize, and scroll on mobile.Prototype. If you go through the underlying html and css, it's very hackey.• Having search in-line with the rest of the profile bar(?) further highlights the issue that there is too much going on there, see point 1.B • Some easing/animation might help, when you scroll quickly some weird flashing/bouncing happens that is disconcerting, and makes me cringe a bit.I'm using a library called "waypoints". It's possible for us to hook animations into it (when element X arrives at scroll position Y, activate animation Z) but I wasn't so much concerned with that.On May 19, 2013, at 1:47 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sun, 19 May 2013 09:07:30 +0200, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
This. In my opinion mving the location of search and logo on scroll means that at least one of the designs - the "basic" one we have right now, or the scrolling one - is horribly broken.
I think both, and I'll explain why below.Also, why is the personal menu kept on scrolling instead of the article tabs? Is it considered more important now?
Yes, if only for access to the Echo badge. In the future, there may also be other important things that show up there that may need permanence but Echo is the primary use case right now. On to what I think are the main navigation problems. It is my humble opinion that the primary issue we have is the tabs. I've got a couple reasons why I don't think they work the best, but the primary one is this: They are not directly tied to the content that they control. In the Vector design, the user is trained to understand that "things inside the blue line" are content, while what is outside of that is "chrome". Further problematic is mixing *content* actions within *site* actions (via the sidebar). Moving the various tab functions inside of div.#content, perhaps directly under the article title, will tightly bind them to the content. (I also don't think they should be tabs. We break our metaphor when we have *two* active tabs at any one time.) This then leaves us plenty of space in the top for all sorts of fun stuff - like making the search box full width. I can probably throw something together to illustrate this without much effort.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
This to me shows as Bartosz points out - we need to rethink the vector design. Like others have commented I don't think search should move - I agree it is very confusing.
Nice though and I'd be keen to see this seen through to completion.
On Mon, May 20, 2013 at 1:01 PM, Brandon Harris bharris@wikimedia.org wrote:
I'm sort of goofing around with an alternative thought right now; it may be better to wait until after that's done and we can talk about everything together.On May 20, 2013, at 12:57 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Brandon this is good stuff! Maybe we need a group whiteboard session to address a few legitimate concerns and post an updated prototype to the media wiki page?
On Sun, May 19, 2013 at 12:26 PM, Brandon Harris bharris@wikimedia.org wrote:
Replying to all comments, in line. This is an interesting exercise because it brings (back) up some flaws with our current information architecture. I'll get into that at the bottom.On May 18, 2013, at 7:21 PM, Steven Walling swalling@wikimedia.org wrote:
Key consideration: how would this interact with the fixed toolbar of VisualEditor?
I should expect that the VE's toolbar would dock just below the user toolbar.On May 19, 2013, at 12:07 AM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Great mockup Brandon,
few notes • A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
Yes, I agree. This came out of our conversation the other day about reducing the number of possible search fields that may exist on a page and having them perform multiple duties. I'm not happy with the current behavior. There are a couple other ways to solve for this that come to mind immediately, but they all have flaws of some kind or another: 1) Leave the search at the same vertical point and hiding the tabs on scroll, increasing the width of the search. - This increases the vertical size of the docked toolbar (creates problems with the existing event with the logo branding, but nbd) - There's interaction issues with "when should the tabs disappear) 2) Collapse the user tools to an icon or two (so that the Echo notifications are still visible) and make the transition of the search box more elegant 3) Move the tabs (see below)• just played around with the visual editor fixed header. I think that we might be able to handle the visual design of VE slightly differently (skin change?) to further differentiate it from the fixed header or vice versa. In an edit mode having two fixed headers might not be the end of the world…it might, who knows?It is my fervent hope that "edit" mode manages to eliminate a lot of controls on the page that I don't think need to be there. Search, for example, doesn't make a lot of sense to me in edit mode.• search FREAKS out on browser resize, and scroll on mobile.Prototype. If you go through the underlying html and css, it's very hackey.• Having search in-line with the rest of the profile bar(?) further highlights the issue that there is too much going on there, see point 1.B • Some easing/animation might help, when you scroll quickly some weird flashing/bouncing happens that is disconcerting, and makes me cringe a bit.I'm using a library called "waypoints". It's possible for us to hook animations into it (when element X arrives at scroll position Y, activate animation Z) but I wasn't so much concerned with that.On May 19, 2013, at 1:47 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sun, 19 May 2013 09:07:30 +0200, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
A.search box moving location feels weird, B.I can see this change being part of a a header reorg in general but having search changing position on scroll feels a little funny
This. In my opinion mving the location of search and logo on scroll means that at least one of the designs - the "basic" one we have right now, or the scrolling one - is horribly broken.
I think both, and I'll explain why below.Also, why is the personal menu kept on scrolling instead of the article tabs? Is it considered more important now?
Yes, if only for access to the Echo badge. In the future, there may also be other important things that show up there that may need permanence but Echo is the primary use case right now. On to what I think are the main navigation problems. It is my humble opinion that the primary issue we have is the tabs. I've got a couple reasons why I don't think they work the best, but the primary one is this: They are not directly tied to the content that they control. In the Vector design, the user is trained to understand that "things inside the blue line" are content, while what is outside of that is "chrome". Further problematic is mixing *content* actions within *site* actions (via the sidebar). Moving the various tab functions inside of div.#content, perhaps directly under the article title, will tightly bind them to the content. (I also don't think they should be tabs. We break our metaphor when we have *two* active tabs at any one time.) This then leaves us plenty of space in the top for all sorts of fun stuff - like making the search box full width. I can probably throw something together to illustrate this without much effort.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design