Last modified: 2014-08-14 22:19:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65419, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63419 - no path to Special:SpecialPages
no path to Special:SpecialPages
Status: NEW
Product: MobileFrontend
Classification: Unclassified
Feature requests (Other open bugs)
unspecified
All All
: Low enhancement
: ---
Assigned To: Nobody - You can work on this!
http://abj.jidanni.org/index.php?titl...
:
Depends on: 63459
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-02 15:10 UTC by Dan Jacobson
Modified: 2014-08-14 22:19 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2014-04-02 15:10:42 UTC
The Special:SpecialPages are all nicely mobile formatted. However, there is no way to get to them from Home or Menu etc.!
Comment 1 Bingle 2014-04-02 15:15:09 UTC
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1834
Comment 2 Jon 2014-04-02 16:02:14 UTC
This is currently by design. You can navigate to it via the search engine. The rationale being that these are not as important to the average user and real state is expensive.
Comment 3 Dan Jacobson 2014-04-02 16:32:48 UTC
All I know is one more link in the menu still wouldn't make it reach the bottom on many devices, and e.g., Facebook and YouTube have yards long menus...
Comment 4 Jon 2014-04-18 17:34:16 UTC
Yard long menus are very very bad. Let's not copy that bad design and make this a dumping ground for links :)
Comment 5 Florian 2014-05-20 08:03:02 UTC
I agree to Jon, SpecialPages aren't much important for the most of users, even less on mobile devices. Users, who need the Special pages know, how to navigate to them. In my opinion, the left side menu is better, if it is as short as possible :) If Special page link will be added, in next time, the next one wants the FAQ link or something else :)
Comment 6 Dan Jacobson 2014-05-25 23:35:55 UTC
Note that many users only contact with the web will be via mobile, so they will never know what they are missing.
Comment 7 carchaias 2014-06-05 14:48:17 UTC
From the users view please consider that all pages within the Mediawiki:Sidebar are not accessible easy to the user who is familiar with the PC-Browser interface. Most of them don't know the Special:SPECIALPAGENAME to use it in search. Furthermore they are cutof some essential Namespaces like Help: or Project: .
For me I "expected" the toolbar-content of Mediawiki:Sidebar behind the menu button on first use, wondering its not there. Now a couple oft time later I found that bug discussion here and have to vote: +1 for more links in the menue.

From the wikiauthors view please consider, that many wikis use customised Mediaki:Sidebar to shortcut access from "everywhere" to elementar wiki-pages, Categories or Namespaces or visually cut users from special pages - that is the easiest and most comfortable way to realise this. Authors 1. have to know that links in sidebar are not accessible in mobile view and 2. have to implement an alternative by adding additional links on Mainpage or so. And even this is not that comfortable for users as they have at least one more click to do.

So I would prefer some very simple Parameter  $wgEnableSidebarInMobileMenue = "true"; within LocalSettings.php or the like. That would help a lot. Leaving the admins decision free if he/she wants long menus or not. For all my wikis and their Users MobileFrontend is some "restricted-version" of the wiki because they are not knowing how to access the content from Sidebar via the search (and even that i feel much more uncomfortable).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links