Talk:Athena
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Intrawikis | 4 | 19:32, 26 April 2013 |
| When will it be ready? | 0 | 18:58, 8 December 2012 |
| Documentation of this skin | 0 | 22:11, 29 October 2012 |
| feedback, landing pages and footer | 0 | 16:34, 7 August 2012 |
| Text width | 0 | 17:18, 27 July 2012 |
| Media queries | 2 | 23:37, 22 July 2012 |
| Comments on the new design | 1 | 15:47, 18 July 2012 |
| 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 |
 First page |
 Previous page |
 Next page |
 Last page |
You mention in the page how this is going to help the large proportion of people worldwide who speak two or more languages. But we currently have nearly 300 language versions of Wikipedia and very few editors will speak as many as 10% of them. Would it be possible to set your user preferences to record multiple language preoficiencies as opposed to just one language as at present, and then reflect this information in the prominenmce you give them. So oher versions in languages that you speak would get prominence, other versions in languages that you don't speak are as discreet as today. WereSpielChequers (talk) 08:17, 16 September 2012 (UTC)
The Extension:Translate adds a field to m:Special:Preferences#mw-prefsection-editing where we can add a list of "Assistant languages" which we may use when translating pages by its interface. It would be good to have the same (kind of) list used for interwikis. Helder 15:05, 22 September 2012 (UTC)
I think Wikidata have taken care of Interwiki links for multiple languages.. It will be helpful..
No it won't, but this proposal by Pau/the Wikimedia Language engineering team will: http://thread.gmane.org/gmane.org.wikimedia.mediawiki.i18n/662
Hmm.. I see..
When is Athena expected to be released and fully functional for the Wikis? Specifying it would be good in the corresponding article. Thanks (P.S. I would like a copy of the reply on my en wikipedia talk page too, if thats not a problem)
Heiya, I would like to suggest that this skin is documented at Skin:Athena as soon as it is deployed. Cheers
Dear Brandon,
thanks for your marvellous essay on Wikipedia:Wikipedia Signpost/2012-08-06/Op-ed.
Feedback: The current approach is great for all the reasons you've heard a million times already. I associate myself with those criticising the prevailing black colour and prefer a dark gray (see below). While the implementation of a variety of features is already visible in your mockups, some are not - that's great and part of the process. Noticing the inability of an average user - independent of age, gender, educational achievement or profession - to find the sister projects in a Wikipedia article is a pain in the arse. The Beatles mockup involves a gallery at the top of the article, which is a step in the right direction. I'm clueless on a proper way to indicate sister projects where appropriate: when looking on the article about en:Germany I might actually want to see more images about it in a convenient way.
Landing pages: Several domains such as www.wikipedia.de www.wikipedia.com and the like are currently controlled by a variety of people and institutions. Those with affiliation to the WMF could rethink the design of these pages as well. Crawlin the web some time after your presentation at Wikimania I noticed this redesign approach: http://www.chipotoole.com/wikipedia.html - the simplicity of a Google-ish interface speaks for itself. The homepage design approach features a dropdown solution to search for images and other stuff. Searching for images could be a great feature - it'll automatically forward people to the Commons. However, redesigning that platform is a utterly different project ;)
Footer: The footer of http://reportcard.wmflabs.org/ makes use of a dark grey as well. The three column layout and WMF's slightly darker logo result in a rather subtle, inconspicuous impression. Looks good to me. An embossed WMF logo could be appealing as well.
In a nutshell: I don't intend to say that these suggestions are the best solution - in the end any design approach remains a question of personal taste. A combined colour swatch of white, blue (see header section of the reportcard - similar to your edit button) light and dark gray features both: a reminiscence to the current design and a fresh, new interface experience. Your feedback on my suggestions above would be appreciated.
Regards,
Hello! I attended the Wikimania talk on Athena and I loved the screenshot! Having a huge picture on top looks cool.
Anyway, I'm writing here because I'm very concerned with the width of the page text. It's often recommended that each line of text should have 40-80 characters, depending on the depth of the content. Since Wikipedia is very deep, I expect 70-100 characters, and no more. But now I have around 200 on this laptop computer and even more in my desktop computer. So my question is: are you considering having an option in Athena to reduce text width to some configurable em size?
Also, if this happens, the rest of the width could be used for image galleries, not to mention those huge tables. Thank you! --NaBUru38 (talk) 17:18, 27 July 2012 (UTC)
The design looks great, this is a much-needed advancement. Is this intended to be a reverse-compatible skin, or will this be a ground-up codebase rewrite?
I'm attempting a responsive skin now, but am having trouble getting media queries through the resource loader -- any suggestions about workarounds? (e.g. how to add a vanilla <style> tag to a page header?)
Thanks for your efforts --
Right now we're thinking about a skin that is responsive (there have been some prototypes using a different design), but we're not at the implementation phase yet. As far as resource loader questions go, I'd suggest asking Krinkle (Timo) about them.
- The new design shows a large picture placed above the article, with the title of the article placed in front of it, in white text. The image is shown matching up perfectly to the width of the screen. How would this be possible to do on all screens?
- I can't see having a 100%-width image over every article working. Many topics simply don't have a good "representative" image. What would be at the top of, say, w:Adverb, w:Enlargement of the African Union, w:Telecommunications in South Korea, w:Dunning–Kruger effect, w:Sainte-Laguë method, or w:Languages of Oceania? Even for those articles that could have an image that represents the topic, how many could be 100%-width, ~160px-height image, working well? I'm having difficulty thinking of any article other than w:The Beatles itself that it would work well with.
- The image seems to show virtually everything collapsed under a "more v" menu. That's going to make things seriously difficult to find.
- Avatars? Um, that's not going to be liked.
- In plain white, the "Locked" icon loses much of the meaning. The difference between being move-protected, full-protected, semi'd, PC'd, etc is significant.
- What is the "Contents >" bar supposed to be? Navigation based on images? Wouldn't simple text, like the current Table of contents, work better?
- "Search over 4 million articles" heavily overemphasizes article count, in my opinion, and isn't very clear. Additionally, it doesn't translate well for new wikis :/ .
- The new GlobalProfile pic looks nice, though I think it would be helpful if all parts of it were customizable, so users could, for example, decide to not display their uploads on their user page, or relocate the contribs box.
I really liked the old design, at least the general structure of it. The new version, not so much...
I haven't seen the old version Yair rand refers to, but I really like this concept as it stands now. I have a couple of concerns -- one being the use of advanced interface elements being unusable on older browsers (both mobile and desktop) or older hardware (again both mobile and desktop), and the other the predominance of greyscale images in the examples. For that latter point, note that both images featured on the Beatles mockup are greyscale, which serves to emphasize the "primarily monochromatic theme" touted in the Color Scheme section... I wonder if the effect of this "minimal and bold" color scheme will be muted or disrupted if coupled with full-color article images. LtPowers (talk) 15:47, 18 July 2012 (UTC)
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.
First page |
Previous page |
Next page |
Last page |
