I’m going to create a thread per section to collect wireframes and focus discussion in this next phase of refinement. Props to @r-a-y for suggestion.
I’m going to link each set of wireframes we have then please add any wireframes you have and any thoughts you have on the wireframes. Feel free to ‘run with’ people’s ideas too – sometimes a picture can say many words
Other wireframes from the past to also not be discounted:
Just to reiterate from the chat: The tabs to the right of the menu (which is what’s primarily discussed here) is not part of the proposal but merely shows what filters we have to day, when displayed as tabs instead of as a select (and these are replicated for each and every sub item under Activity).
Also from the response so far: The dividers between the “core” functions and plugins as seen above is not something easily achieved and probably not what end users would want anyway. Consider those gone already.
How would this look on a cell phone?
It is my belief neither tabs nor vertical navigation should be considered. They are both outdated examples of fixed layouts from times past.
BP should not be a Facebook clone.
@nat0n: I don’t recall discussion against a dividing option if it came up. That was something that people said could be explored to find out limits. I think everything is still open so to speak for ideas.
@FIQ: Adding a ‘mobile menu’ is usually down to the theme not something that we’re talking specifically here. What shouldn’t happen is we make it hard for themers to work with . Whatever we do has to still work on touch devices and phones, but the theme designer would decide the implementation of a mobile menu. Remember we’re not designing a theme here.
I don’t think anyone in this project wants a Facebook clone so no need to worry on that front
Everyone keeps saying you are not designing a theme, but these choices directly effect themes.
If these wire frames are to be of any use they should be on grids that show pixel size.
Lets pretend this is going to be used on a theme that is 960px wide. Now lets subtract. How wide is the vertical nav going to be at a minimum, subtract that. If this is say the activity stream how wide are the avatars going to be, subtract that. Now subtract a 300px sidebar. Then factor in all the padding, subtract that. What are you left with for the content?
If what you are left with is too small or crowded you’re only option (without a ton of coding) is to reduce the sidebar. Therefor you are designing themes here, even if you don’t think you are.
I would always as I’ve said suggest a theme should have it’s own mobile menu rolled in. I am not though anti that being up for consideration as rolled into the default components. I think it may add too many aspects but it’s worth considering.
Nobody here seems to get what I’m saying. Go back and read what I wrote again and forget I mentioned mobile. That was only to illustrate a point about narrow themes that may use BP.
According to my rough calculations, the content area would be only 480px wide using this theme.
I did read it. I didn’t take the tabs into account in my calculations.
That is using 2010. These issues will multiply fast for those with more complex themes, such as 3 columns, etc. This also makes building a responsive theme for tablets, mobile etc much harder.
@fiq: Ok, yeah, that might be one way to design those. Or as a 20/80, 40/60 or 50/50 width – you can do whatever you want in the theme CSS. It’s not in this thread’s proposal to define that, just to come up with ideas on what a side navigation _is_ and what to find there. If you want to lay out the elements differently, go ahead! Any theme will override the default width, whatever that may be. Or are you suggesting there is not room for this kind of navigation at all..?
Yes, there is no room for it.
It only works with wide or full width layouts. At a minimum the vertical menu would have to be 140px wide to be readable. Then say another 15px for the left padding. That’s 155px less for the content, no matter the theme. I believe the content area should be as wide as possible not only for more flexibility, but also because it is the most important thing on the page.
@FIQ : Why are you dealing in px if the point is mobile? % / rem = mobile.
The point wasn’t mobile, but if it was px still apply. My point is the content area should be as wide as possible and vertical navigation is evil.
@fiq: what’s evil and not is highly subjective but I get your point with the “too many columns” dilemma. If you’re aiming for a 960px theme then maybe a CSS fallback to tabs (or a show/hide functionality) would be more appropriate than showing everything at once. Still, on wider layouts we need to decide on how menus should look and behave. Hence this thread.
edit: On a related note, the layout as seen in the profile thread also needs some responsive design for smaller screens. Or for larger, depending on if it’s mobile or desktop first you have in mind.
I think the layout on ‘any of our wireframes so far’ needs a responsive adaption. This is why we wouldn’t be using px for creating anything we’d use % and rem – therefore scaling down. There is also further argument for swapping in / out things as are needed.
One point to be very careful is not design purely for any size – be it large or mobile. We can adapt but we shouldn’t focus and at this point we shouldn’t brand things good or evil.
So.. lets get back to wireframe discussion if possible and bring things back into focus
I don’t like the idea of relying on js, but have you looked into scroll tabs?
Perhaps use a select box as a fall back.
@FIQ: I don’t think anyone said ‘rely on js’ – I would certainly never suggest that. You can switch things without js … media queries aren’t js.
scrolling tabs does start to veer towards themeing though once again; if addressing the concern of hori tabs then dropping the notion of tabs for buttons that when splitting to second line do not look so out of place would be better.
agree about buttons but what about using a select for the secondary nav? It would look in place with the sort filter for activity and sub pages could load via ajax. Selects are mobile/responsive ready
Another option would be to do both. You could make it an option within the short code for either vertical or horizontal nav. That way the end user can decide which works better for them.
You must be logged in to reply to this topic.