Help
Add this page to your book
Show book (0 pages)
Suggest pagesTalk:Athena
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| History icon use | 0 | 13:11, 1 April 2012 |
| Discuss new Info Boxes | 1 | 06:14, 1 April 2012 |
| WikiGo Mock design | 0 | 16:19, 7 February 2012 |
| WikiGo | 0 | 13:16, 21 January 2012 |
| New Articles Page Design | 0 | 14:25, 5 January 2012 |
| Some initial feedback | 0 | 22:46, 11 December 2011 |
| Additional links in header/footer | 0 | 20:35, 7 December 2011 |
| Some intuitive likes and dislikes | 12 | 20:34, 7 December 2011 |
| New Desktop Website Design | 0 | 18:07, 4 December 2011 |
| More comments about the heavy use of black, and a simple solution | 1 | 21:11, 28 November 2011 |
| Browser compatibility | 5 | 21:50, 13 November 2011 |
| Smartphone footer text | 2 | 20:22, 13 November 2011 |
| Language switcher on the tablet version | 2 | 20:17, 11 November 2011 |
| Namespace icons | 1 | 00:23, 11 November 2011 |
| Color scheme | 1 | 02:42, 9 November 2011 |
| Wow. This looks incredible. A couple questions: | 8 | 18:47, 4 November 2011 |
| Notifications | 1 | 23:33, 2 November 2011 |
| Great stuff, go even further! | 1 | 22:42, 2 November 2011 |
| Let the experiments begin! | 1 | 20:50, 2 November 2011 |
If the icon used in the "History" button of this design is visible on essentially every page, it would probably quickly cause the icon to be synonymous with the history page, allowing it to be used alone, without accompanying text, to symbolize history page links. This would make it possible to redesign watchlist and recent changes lists, replacing "hist" everywhere with a smaller version of the icon.
Discuss New Info boxes for WikiPedia : Grande
I'm going to have to say that I don't think that this design hits the mark.
The purpose of an infobox is to show at a glance various bits of information concerning the topic at hand. Your design, while less "cluttered", requires significantly more clicks to get even minimum amounts of information. Each click is a commitment; infoboxes should not require them.
wikiGo Mock Design (Still in Progress ; track progress here : Grande)
Hi all, I think the development of this new skin is one of the most exciting and innovative changes for Wikipedia for a long time, and to that end I hope that I can contribute towards its development in a small way. I am conscious that what stands the best chance of being helpfull is deconstructed feedback, not only saying what I like and dislike, but why I am worried about certain elements and excited about others in terms of the user experience. To that end I have started a longer more detailed post, but I think for these kind of thing "first impressions" do count for something and so I though some quick feedback would also be helpfull. I am mostly talking about the tablet experience, as that is the platform I have most experience with.
My overall "first impression" of the design is that it contains alot of exciting elements (the blue edit button, the strong colours, a much more prominent search box) but that equally the design does not hold up as a cohesive whole. What I mean by this is that many elements seem to be conflicting with each other. The big search box is (presumably) designed to make search easy and a main form of navigation, but it is surrounded by a sea of smaller buttons that will be easy to hit by mistake with finger on a tablet screen (compare with google for iPad which puts a layer of white space all the way around its search box.) The design is rounded in some places (like the blue button) and sharply angular in others (the jutting horizontal bottom edge buttons) which seems to create a discord in the design.
The new "blue edit button" is another example of this. As far as I can see it has been placed on a grid with the gutter that will show inter wiki links, but it is the only thing contained within that "grid" by default and as a consequence disrupts the article flow ( the smaller edit buttons below are also not changed at all, but retain fully their old design, rather than a new small "edit button being developed to match the top one, another example that seems to create dischordance between elements).
I also noticed that your mockups don't seem to include mocked up browser chrome, which will be present unless the user uses an app to access the design. Such chrome does (on the iPad) push the article content quite a longway down the page with the big top bar (certainly over 1/4 of the way down), I suspect this is something you probably know already, and indeed I am not sure if this is a pronblem or not (on balance I felt it was still high enough) but it was very noticeable as a difference from the mockup on a pc screen. As I say these are only my initial thoughts / criticisms, and I do emphasise there is alot to like here though, but if you have any thought on the issues I would love to here it and might mean I can be more helpfull in my more detailed feedback. Ajbp 22:46, 11 December 2011 (UTC)
Wrote a description of links in adaptive portlets, perhaps its of interest in the new Athea skin.
Rethinking the user experience is always a pretty monumental undertaking, so kudos for diving in and exploring some radically new ideas.
Likes:
- Really glad that you're building a single model that incorporates mobile, tablet and desktop experience. This is indeed necessary.
- It may be sensible to abstract this a bit further: screen size and input methods (mouse vs. touch vs. voice ...). Netbooks, for example, have small screen size, but typically no touch screens, so a "tablet UI" that assumes touch may not make sense there. In general, I notice that the word touch does not appear in the design docs, but I think we have to talk and think very explicitly about touching vs. clicking vs. speaking.
- Really happy to see a big search box in all views. I think even in Vector, the search is still too modest.
- Calling out "Edit" or other important calls to action makes a lot of sense to me.
- I agree that we should definitely experiment with more dynamic UIs where it's easy to collapse/expand large elements, beyond what Vector is doing with the sidebar sections.
- Generalized user notification mechanism FTW. This is definitely an increasingly common user expectation and it makes a lot of sense to build on this paradigm.
Dislikes:
- I'm not a huge fan of the heavy use of black. It makes me think "death notice". Perhaps it's because of the overall size of the black areas. I also don't love how much the content area is being pushed down in the desktop view.
- "Upload file" really needs more thinking in terms of where it fits in the hierarchy. Maybe it's sometimes a call-out action (when there's a great opportunity to add an original media file), sometimes not? In any case, it doesn't fit with the navigational links.
- With the "context" navigation at the bottom and the "edit" action at the top, and some other actions again at the bottom, we may be negatively impacting navigation efficiency. In Vector, it's fairly easy to switch modes, take page-level actions, etc. with relatively high navigational efficiency.
- The fixed floating/disappearing nature of the different elements doesn't yet intuitively "click" for me, and I've seen floating elements get in the way quite a bit. Obviously I'd love to try this in an interactive prototype, though.
- "Random article" is our third most popular page, even more popular than search! [1] [2] I don't think that's just because it's in the sidebar. People like viewing random articles. It deserves a nicely accessible location.
Need to ponder:
- Since this is a pretty future-oriented design, we should think about the "edit mode" altogether. With the Visual Editor, we should be able to transform sections of the page, or the whole page, into edit mode without the heavy mode switch that's currently required (ideally without a full page reload as well). What will that mean? Perhaps tapping paragraphs or selecting text makes an edit action available; perhaps there are other implicit or explicit triggers for edit mode beyond what we currently have.
- In the same spirit, let's think about other advanced functionality: surfacing location information, using a mobile device's voice features, etc.
Finally: Whether you like or dislike Vector, it went through lots of iterations and was very much data and research driven, so I do think it's important to not forget some of the lessons learned from the research, as well as some of the ideas from the earlier designs. If you haven't seen it yet, you'll find a lot of the thinking and research that went into the usability initiative at http://usability.wikimedia.org , and there are lots of PDFs with earlier design iterations there as well, e.g.:
(Replies to this are broken up so that we can create separate threads about specific issues and I can chunk out my responses).
It may be sensible to abstract this a bit further: screen size and input methods (mouse vs. touch vs. voice ...). Netbooks, for example, have small screen size, but typically no touch screens, so a "tablet UI" that assumes touch may not make sense there. In general, I notice that the word touch does not appear in the design docs, but I think we have to talk and think very explicitly about touching vs. clicking vs. speaking.
- I was talking with Tomasz about this exact thing, and how we really are talking about resolutions and capabilities rather than specific device types (mobile/tablet/browser). In effect, though, we have arguably four "near term" target resolutions:
- Smart phone (small display, touch oriented)
- Touch tablets (medium display, touch oriented)
- Notebook computers (medium display, mouse oriented)
- Desktop computers (large display, mouse oriented)
However, we can't discount the Future, where something may be inserted into home theater devices (with kinetic and motion recognition inputs) as well.
Except in a few specific locations, I have avoided talking about "touching" versus "clicking" or "swiping" because I didn't want to get hung up in the mechanics of how things behave just yet (this is something that we nearly always bikeshed on). The one area I've been more explicit about it with is with the behavior of the sliders and top bar on mobile devices.
I am going to update the main document with more descriptions about various "device" targets as well as some rationales about choices (for example, large search boxes are arguably more important for large resolution, mouse driven interfaces, since Fitt's law makes it hard to get a mouse there with accuracy very fast).
I am thinking about some other devices.
- the first is old phones, which are still present in Europe for people which don’t renew their phone or don’t want a smart phone, and probably in Africa (I don’t know the state of the market there) -> small display, key-taping oriented.
- the second is e-book readers (like the Amazon Kindle), although these aren’t still widely used and web browsing is not their main feature, but web browsing is possible on many devices (although quite painful, at least on a Bookeen Orizon). Perhaps it shouldn’t be taken into account now as it, but kept in mind (particularly for projects like Wikisource, or Wikibooks), I heard people talking about a mix between e-book readers and smart phones in the future, although it depends of the evolution of the technologies and practices. The current specifications of such devices are: small display (600x800 on most devices), grayscale only (generally 8 or 16 grayscales), touch oriented, and the current most relevant (here) specificity is the time of refreshing (=renew entirely the screen, mandatory for any change in the display) of about 1 second.
- it should also be taken into account devices for disabled users: Braille terminals and text-to-speech softwares; these could probably taken into accound during the implementation but it’s worth keeping them in mind.
I'm not a huge fan of the heavy use of black. It makes me think "death notice". Perhaps it's because of the overall size of the black areas. I also don't love how much the content area is being pushed down in the desktop view.
- I chose black to make a very stark contrast. I agree it's an extreme, but I'm not sure that isn't what is warranted. There are other colors and shades that can be played with, of course, but a major, major problem with nearly every other skin is the fact that the site chrome is too easily confused with the content objects. Better, in my opinion, to make the distinction heavy-handed.
- Stronger color can also work here, but color psychology can cause interesting sub-issues. Blues and greys are masculine colors, for instance.
- It's interesting that you think the content is being pushed down in the desktop view. It's true that the content is lower (by five pixels, actually, in the first example header - the alternate header is significantly "shorter"). However, my visual impression is that it isn't (and I think this has to do with the smaller globe logo).
Heh. It's possible that my mind did some of its own scaling based on an assumption of how large the logo is. :-)
One way to slim the bar (at the expense of even further logo shrinkage or a layout change) might be to only have a single link bar above the search box, and to alter its appearance based on logged in / logged out status. If you're logged out, you get a bunch of popular nav links + the login link; if you're logged in you get the personalized links + a single "Navigate" dropdown that takes you to your most frequently used pages.
So, you mean that we would change the size and appearance of the top bar based on whether or not the user chooses to include the navigation links? That's an interesting idea.
Anons get the "full bar", with the globe, and so do most users by default, but you can set prefs that show/hide sections, until you get the "minimal" bar (there's a screenshot of it). I like this idea a lot.
(Two comments mixed here since they're kind of related) "Upload file" really needs more thinking in terms of where it fits in the hierarchy. Maybe it's sometimes a call-out action (when there's a great opportunity to add an original media file), sometimes not? In any case, it doesn't fit with the navigational links.
and
Since this is a pretty future-oriented design, we should think about the "edit mode" altogether. With the Visual Editor, we should be able to transform sections of the page, or the whole page, into edit mode without the heavy mode switch that's currently required (ideally without a full page reload as well). What will that mean? Perhaps tapping paragraphs or selecting text makes an edit action available; perhaps there are other implicit or explicit triggers for edit mode beyond what we currently have.
- Yes, "Upload File" really doesn't fit anywhere (except perhaps the "gadget gutter"). This is probably why it was unceremoniously shoved into the "toolbox" - no one knew quite what to do with it (and we still don't)
- NeilK has a pretty strong opinion that it doesn't belong anywhere except in an "edit mode." To that end, I've been thinking about how an "edit" mode works, and it would be rather simple (at least at tablet+ resolutions):
- We just take over the gadget gutter and put all pallettes and toolbars there.
- The "Edit Page" button then becomes and "activate edit mode" function.
I tend to agree that upload belongs in the editing tools; most upload operations should be expected to be "in context" of a page or category; either you're adding something directly to the page, or you're pushing something in to be available for view or discussion.
(For instance somebody who's just submitting photos they're taking while wandering around with their smartphone should be able to, say, push the photos up onto the talk page / discussion stream of the page with a suggestion "hey somebody might want to clean this photo up and add it to the article!".)
Right. I think the major use cases we have against this are pretty much about uploading to commons and the like.
Well, in a perfect world, no user should have to understand the distinction between Commons and Wikipedia. If their license is appropriate for Commons, it should go there. If it's only appropriate for the wiki they are talking to, it should go there.
I agree that in a mobile context, adding a photo to a page may well be the #1 contribution activity. So I'm not against it having a prominent place especially on mobile.
(I'm just of the opinion that we should carefully scrutinize every link. And that the distinction between "Upload a File" and "Edit this page" seems to more about how we wrote the software, rather than any division of these tasks in the user's mind.)
Anyway perhaps we should consider a new paradigm for photo submission to Wikipedia -- some kind of grab-all where uploaded files live at the bottom of the page. Then editors can fish photos out of that area for use elsewhere in the article. We'd have to be careful that this results in good submissions, though, since it would be easy to add dozens of photos that way.
With the "context" navigation at the bottom and the "edit" action at the top, and some other actions again at the bottom, we may be negatively impacting navigation efficiency. In Vector, it's fairly easy to switch modes, take page-level actions, etc. with relatively high navigational efficiency.
- Regarding Vector's tabs (and Monobook's, actually, before it): I actually find the opposite to be true with regards to new users trying to understand what is going on.
- I've heard varying comments from users (many of whom say that they can't even find the edit button). They see links that may or may not be tabs (since the UI isn't very clear on that fact). This is further compounded by the fact that it appears that there are two tabs active at the same time (because the "sub-tab" metaphor isn't well-described).
- I think that the strengths of "in-line sub-tabs" will become clearer in a functional prototype.
The fixed floating/disappearing nature of the different elements doesn't yet intuitively "click" for me, and I've seen floating elements get in the way quite a bit. Obviously I'd love to try this in an interactive prototype, though.
- I've seen similar things work well on several sites but not as "heavy weight" as this is. Obviously, it's a known, workable pattern in mobile devices. Facebook uses floating elements rather well. Again, this is a prototype-noticable thing.
Last one:
Other stuff:
"Random article" is our third most popular page, even more popular than search! [1] [2] I don't think that's just because it's in the sidebar. People like viewing random articles. It deserves a nicely accessible location.
- I actually thought I had it placed in the footer but it must have gotten lost somewhere. The contents of the "prime menu" are things that we want to look at very carefully, I think. There's a lot of cruft there.
In the same spirit, let's think about other advanced functionality: surfacing location information, using a mobile device's voice features, etc.
- I've been thinking a great deal about utilizing this type of stuff - especially location-aware technology. I'd love to be able to do things like throw up a "work list" based on your location (and, in fact, we might be able to do something with notifications and such not: "Hey, we noticed that you're near this church, and we'd like a photo...").
Right, so like a bunch of other people, I'm really, really not into the idea of the heavy black bars up top for the desktop version. In fact, I'd probably switch back to vector just to avoid them, and that would mean that I'd lose whatever newfangled gizmos you all stuff into the new version. Doesn't leave me with many good options.
Here's a really simple solution though: Make changing the color schemes an option. Lots of websites do this to accommodate people with different visual preferences. I envision being able to go to "your preferences" and selecting between a black dominant (default), a white dominant version that approximates the colors of the current default layout, and a grey/light blue version that approximates the colors of the older layout, which some folks still use.
It shouldn't cause any more work for the coders, and it's really not that hard to do for the art department, since all the design is done and the color schemes have existed for years, and it will make a large number of users very happy.
A significant chunk of mobile users (about a third?) use browsers that don't support fixed positioning. What will the site look like for these users?
That's something that a prototype will probably have to experiment in solving ideally, rather than something that would end up changing at all.
There are different ways to do that kind of ui:
- Fixed positioning. This has the mentioned issue that most mobile browsers don't support it.
- JS. The classic trick where you dynamically relocate the location of the ui chrome as the page is scrolled. This may be possible on a mobile browser, though it'll probably be a last resort.
- overflow: auto; It's possible to create a ui like this without fixed positioning things by making the entire page the height and width of the device and then making the content area scrollable. The downside is that this may require two finger scrolling in places where it was possible to scroll with one finger. Though there may be ways to work around that, like implementing a scrolling hack using the browsers touch events.
So really rather than anything changing, the prototypes need to experiment with different ways of making this ui possible and find the best way it can be done.
Do any of these work reliably across browsers? I'm pretty sure a bunch of old-ish browsers don't support the overflow property, and some browsers have problems with the scroll event and/or touch events, I think. Many browsers do support position:fixed, and for them it would be preferable to use it. Would it be possible to serve position:fixed to some browsers, JS/overflow-based workarounds for those that don't support it, and some entirely different design for the hopeless (or non-javascript supporting) browsers?
Right now, I think we'd do best to focus on what we want to see rather than be held back by arbitrary problems with outdated browsers (many of whom will have fallen into pure antiquity or below our support threshold by the time something like this reaches maturity).
There's been a couple of discussions about this. Without volunteer developer involvement, Athena is at least 6 to 8 months out on the time frame (unless we magically attract contractors who want to work on it).
My current attitude is "focus less on cannot and more on the future". Making Athena work in IE 6 is probably impossible, but maybe that's okay: it would clearly be experimental for much of its life.
Stick with something as close as possible to the W3 standards, hack around if possible and serve something else (something WAP-ish) if Athena (or whatever it will be called) can't be used.
That is (hopefully) what we'll be doing.
We can't just say "screw it" with every old browser or system, obviously. But we also can't continue to support decades old technology - especially technology that has reached End of Life.
Since this is something that would happen "along side", I think it's okay to be more bold and experimental than we normally are.
What is the difference between "Desktop version" and "View Wikipedia as Classic"?
Heh. That's an error in the screenshot. Only one of those should be there.
We're having discussions on how this thing (the switch between mobile and desktop) should be handled; that was one of the directions but it appears both made it into that screenshot. I'll fix it and upload a new one when I get a chance.
I think that having a language switcher on the topbar in the tablet (and maybe the desktop) version of Wikipedia would give more space to the content, specially when the articles contain images and media content. As the language becomes irrelevant while we are reading an article, the switcher doesn't have to be present at all times, at least in the tablet version.
My idea for language switching (Inter-wiki links, really) in the tablet version is that they disappear when you don't need them. This isn't explicitly spelled out in the design document, though (and it probably should be). I just haven't had time to revisit it and incorporate feedback about it.
One of the goals is to totally separate "site actions" from "content actions". Inter-wiki links are clearly content actions.
The images show the "Article" tab having a different icon than the "User" tab. Are there going to be different icons for every namespace?
I think that the icons will vary from project to project. The use of a puzzle piece for "article" is a bit of a conceit for Wikipedia; a "page" icon would probably be better overall. Since nearly ever wiki will have a distinct "user" namespace, I think having a separate User icon would be easily doable.
I think that the icons for distinct namespaces should be site configurable, though.
Light text on dark background: great for reading on small (mobile) screens and probably important for differentiating navigational elements from content.
Light text on dark background: pretty much horrible for reading on the (desktop/laptop) web.
Discuss.
(All pithy statements aside, I think this is a serious problem. Websites that use light on dark color schemes are in the minority for a reason. Is there a way to retain the structural composition of Athena but have a color scheme that isn't so hard on the eyes?)
Interestingly, research says differently.
Most of the time, users operate in either "scan" or "read" modes. In read mode, usually black-on-white is best, but for scanning (such as looking at website chrome) light on dark is better. UX Movement talks a bit about this very thing, actually.
Many years ago (like, 1995) I read a paper that said that "light grey on black" was the best to reduce eye strain and promote readability. Of course, that was back with old LCD monitors, so things are different now. Your question is good, though, so I went a lookin'.
...and I found a reference to the old paper, but not the paper itself. However, this stackoverflow question actually goes into more depth, and with more research.
Wow. This looks incredible. A couple questions:
- This says "Tapping on the screen (anywhere) will cause both the top bar and bottom sliders to re-appear and be usable for manipulation." Does this include when a user is just trying to scroll?
- What will the icon in the top left of the smartphone skin look like on projects other than Wikipedia?
- What is the number next to the "You" icon?
- Are there going to be edit section buttons in the smartphone skin?
--Yair rand 19:16, 2 November 2011 (UTC)
- Answers:
- "Scroll" actions are different than "tap" actions. So no.
- We'll have to handle that on a project by project basis, but I have some ideas.
- In the future, when we have actual "editing interfaces" for mobiles, this is likely, yes.
- --Jorm (WMF) 19:53, 2 November 2011 (UTC)
On the number badge -- I believe the idea is for that to be your 'new notifications' count.
Right now we have a LiquidThreads-specific new-messages indicator and a general User-talk-page new-edits indicator in the regular wiki interface, but not a lot of good general notifications. Hopefully we can get things all merged together in the future -- probably for the near future it'll be the LQT-like message count.
That's exactly what that is supposed to be.
Ideally, in the Great Bright Future, we no longer have such things as "Watchlists", "Your Talk", "Your Contributions", and they're all just filters on "Your Stuff".
That is true, but to be a little bikeshed-ery... I have almost 5,000 pages on my English Wikipedia watchlist alone. I scan them for important things, and I definitely don't want notifications about every change. Preferences on what you get updated on from "My Stuff" would need to be key, just like you can now filter RecentChanges or Watchlists based on bots, anons, registered editors etc.
One more question: When the top slider disappears and the user is still at the top of the page, what will be "under" the slider? Will it just be blank space at the top, or...?
That. . . is a very good question. And I had a think about it, and I've come to the conclusion that in your case right there, that's the only time that the top banner does *not* disappear until it's scrolled off. To do otherwise would result in the text being moved as it was read.
So:
- User loads a page at m.wikipedia.org. Top banner and sliders are present on load.
- Sliders disappear; top banner remains.
- User scrolls down.
- top banner remains at previous location and "scrolls off".
- User "taps" screen.
- Top banner appears in position
- Sliders appear in position.
- User waits about a second
- Sliders and top bar disappear
Which probably makes a more intuitive experience. This is something we'll have to play with.
Is there a distinction being made between "disappearing" and "scrolling off"? I kind of assumed that sliding out would be the normal way of disappearing. Either way, I'm not sure that having it disappear as a result of an action is a good idea, since it really loses the "(Slight panic) Hey, come back! *poink poink* Oh. (Comprehension)" effect. Maybe the L1 header could just be ordinarily underneath it instead of below it? The header isn't really all that necessary/helpful since articles have the title in bold in the first sentence anyway.
(Additional post-having-built-semi-working-version comment: ) I think the "1 second" delay before disappearing is waay too short.
As Jorm knows, I am not a developer-type. I just "hang with them," but he shared the link to Athena - REALLY COOL! I am curious about your plans for the notification button - what are you thinking about notifying people of? New Wikiloves/Barnstars? New messages on talk pages..? I like the interface and I do like the friendliness of it - it's something Wikipedia proper seems to fear in ways, so it's nice to see it being experimented with here. Any chance to help test this I'd like to volunteer - especially if you want a non-tech opinion.
I now have the Beatles in my head!
Talk pages with LiquidThreads enabled (like this one) already send you notifications - when there are unread replies to topics of yours.
The icon is really a placeholder for the Great Bright Future when we actually have a functioning, usable notification system.
Some ideas for notifications:
- Someone has responded to you on talk page
- Someone has made an edit to a page in your watch list
- Someone has responded to your MoodBar feedback
- (On Mobile) There are pages with geo-coordinates near you that could use some photos
- etc.
Mad props. I think this design is great.
I would go even further in getting rid of links, or stuffing them into icons. I see "Random Page" has gone (probably available in the "more" stuff?). We should carefully consider and measure whether things like "Contents" are really useful any more. Yes it will be painful for us, but the more things we can eliminate, the easier it will be for the user to find important things, like "Edit page" or "Help".
"Upload File" is an interesting case. IMO in a desktop situation, it ought to be moved to the editing experience. However, it's also the easiest way for a user on a mobile device to contribute anything -- perhaps they can add a photo to the very article they are reading. Have to think about that.
I see you added an "updated N units of time ago" thing. That's a great idea to get across the idea that this is a living document. I think the "Edit page" thing is very bold, but that's probably about what is needed, if we believe it's an important goal to let users know they can edit.
I like the simple black and white graphics. MOAR of this please. Now the lock and other icons in the title look downright dowdy.
One question, what's are the 3-D elements on the top and bottom toolbar about? Are you trying to suggest that there are "Article" actions and then other stuff? Not sure it's worth ruining the plain top and bottom visual line. I find them a bit of a distraction from reading.
On the bottom toolbar, they are there to help visually indicate "ownership". "View Article" owns a "history" and a "more" sequence, as does "Discussion", etc. It's a way of doing sub-tabs within tabs, if that makes sense.
I envision there to be an animation sequence that moves things around so that it's more viscerally clear to the user upon activation. I just haven't gotten around to making a mockup that explains how it works.
I am currently playing around (deeply) with the "Gadget Gutter" in a mechanism similar to what Google Calendar does. It's tricky - we can put all our ugly bits there, and make sure it's always around (if needed). I hope to get more work on that later.
I'd really like to dive into what of those top menu elements are actually used often, and which ones are simply there due to historical cruft.
I like a lot of the ideas here; I think we should definitely start prototyping some of these layout & control components in MobileFrontend and/or the new (PhoneGap-based) mobile app.
Actually, with a little more work we could probably make a standalone web-page version of the mobile app that we could use to prototype entirely different UIs in regular browsers... Mwahahahahhaha!
That's kind of what I was thinking. I was going to try to experiment with just modifying the mobile front end, but I think that may be too much work (given the plethora of style sheets). Building a standalone prototype that could be *ported*, though, would address a couple things (notably, the transition point between mobile/tablet, etc.)
There's clearly a lot of work here - difficult design problems to solve. But better to start churning now than later, methinks.
