Wikimedia Apps/Wikipedia/iOS/Feedback

List issues below

= V3.1 =

V3.1Beta1
The Settings screen is inconsistent about where you need to tap to get to the settings you're interested in. eg - tapping in the middle of the 'About Us' bar takes you to the about us screen, but tapping in the middle of the Font Size bar doesn't do anything. (you have to tap on the down arrow instead.) Bhartshorne (talk) 22:27, 1 March 2012 (UTC)
 * 34906
 * After trying (again) to get this fixed, I'm marking this WONTFIX for 1.1 - there is technically no way to trigger a select to open from JS. I will gladly and happily be proven wrong :) Yuvipanda (talk) 21:03, 5 March 2012 (UTC)

The Settings screen does not behave in the same way as the system settings screen (or other in the way I expect submenus to work). I expect that I can tap anywhere in the entire bar representing the option rather than having to tap the down arrow to get to the choices. Bhartshorne (talk) 22:27, 1 March 2012 (UTC)
 * This sounds like the same bug as above. Amy i reading it right? Tfinc (talk) 21:41, 2 March 2012 (UTC)
 * No, they're not the same. The bug above says "the rows are inconsistent but I don't care how you resolve it" and this bug says "I want the rows to behave this way". The same resolution could easily fix both bugs though...  ;)  Bhartshorne (talk) 21:28, 5 March 2012 (UTC)
 * See comment above

I expected that tapping the word 'Settings' at the top of the Settings screen would take me back to the main app. Instead I must tap specifically on the left carat to go back. Contrast this to the system settings where the entire word 'Settings' takes you back to the previous screen. Bhartshorne (talk) 22:27, 1 March 2012 (UTC)
 * Within the iOS 5.0 EMU tapping the title bar of any window does nothing for me. You have to tap the button on the left side to do anything.

There are two back buttons in the About Us screen and they behave differently. The top back button takes you back to the settings but the bottom back button takes you back to the article you were visiting. Bhartshorne (talk) 22:27, 1 March 2012 (UTC)
 * 34908

When you don't have any pages in your history the back button is still active. Clicking on it starts spinning the 'loading' circle in the title bar but no different page ever loads. Bhartshorne (talk) 22:27, 1 March 2012 (UTC)
 * 34909
 * Fixed. Thanks for reporting!

On the 'Nearby' screen, I get location markers but no map tiles (example). Bhartshorne (talk) 22:46, 1 March 2012 (UTC)
 * 34973
 * Fixed :)

On the Nearby screen, the attribution (Powered by Leaflet - Tiles courtesy of Mapquest yadda yadda) takes up too much screen real estate. Yes, we want to attribute the provider, but please make it go away or something and stop wasting precious map area Bhartshorne (talk) 22:46, 1 March 2012 (UTC)
 * 34910
 * Leaflet told us we can move their part off into the about section. Phil's talking to the Mapquest folks to see if we can move that too.

On the Nearby screen, about half the time when I tap on a marker the info bubble pops up then disappears immediately. Tapping the marker a second time makes the bubble come up and stay. I'm seems to happen more frequently when there's already a bubble open, but I've seen it when there is no other bubble open as well. Bhartshorne (talk) 22:46, 1 March 2012 (UTC)
 * 34975
 * Fixed

When reading an article, the Search bar should float off the top of the screen when I scroll down, similar to how the email app and the contacts work. You should be able to get back to the search bar by tapping on the title bar (which also jumps to the top of the article). Bhartshorne (talk) 22:52, 1 March 2012 (UTC)
 * Would mostly be part of Glaucus work. See the talk page for a discussion on exactly this.

When you tap on a bubble in the Nearby screen (to load the full article) the screen blanks white and doesn't show the spinning search circle in the same way it does when you load an article by following a link. Only after part of the article loads does the search bar re-appear on the screen. On a slow connection this makes it look like the app crashed rather than it's just waiting for data. Bhartshorne (talk) 22:55, 1 March 2012 (UTC)
 * 34976
 * Fixed

= V2.2.2 =

= Open Issues =
 * if you search for a page nearby, then enter a new search in the search box at the top of the page and navigate to that page, an entry for the searched-for page goes into the history but choosing that page from the history screen takes you to the original 'nearby' page. Example: search nearby and choose the 'wikimedia foundation' page (because I'm testing from the office).  On the WMF page, enter 'Thoreau' in the search box, go to the page, follow a link for 'Civil Disobedience'.  Click the 'nearby' button to go back to the map page, then click the 'done' button to go back to the main screen.  Load the history (by clicking on the clock icon) and tap the entry for 'Thoreau' or 'Civil Disobedience'.  Observe you land on the WMF page, not the intended page. Bhartshorne 23:07, 6 January 2012 (UTC)
 * Should be fixed in the new PhoneGap build Tfinc (talk) 22:54, 1 March 2012 (UTC)


 * on a slow connection, the 'loading' splash screen stays on the page until images are finished loading, even if you the text has fully loaded. When you don't need the images, it's annoying to have to wait for them before looking at any of the content.  The app should allow scrolling even while it is still loading so that the user can read content before all the images have downloaded. Bhartshorne 23:07, 6 January 2012 (UTC)
 * This should be fixed in our new PhoneGap build Tfinc (talk) 22:50, 1 March 2012 (UTC)


 * After looking for pages in the 'nearby' section, if you leave the app then return to the app, you are still buried in the 'nearby' interface and must tap twice back through the map. When re-entering the app for a new browsing session, it doesn't make sense to still be buried in the nearby section.  Exiting the app and re-entering should load up the previously visible article in the main interface, not the nearby interface. Bhartshorne 23:12, 6 January 2012 (UTC)
 * We've heard mixed responses to this. I personally hate getting back to any app and finding that its changed the last screen that I was on. I expect it to resume right where I left off. Tfinc (talk) 22:50, 1 March 2012 (UTC)
 * This bug is now moot, actually. Previously, pages that you had found through the map were different from pages you found other ways.  Now it appears that they are the same, so you're right, it should re-open to the page you were on when you left.  It wasn't the page I wanted to change but the app's understanding of where you were in your workflow.  The workflow's now the same either way, so it no longer matters.  :) Bhartshorne (talk) 22:58, 1 March 2012 (UTC)


 * Formatting of the reference section into two columns is inappropriate for the size of the iPhone screen. The result is 1-3 words per line and excessive wasted space between the columns.  On pages that use the template , it should be suppressed back down to one column.  Example: Cepheid variable Bhartshorne 23:35, 6 January 2012 (UTC)
 * 34787


 * feature request There's no 'open in safari' link in the app. Most iOS apps that show you web pages in some way (eg facebook, byline, echofon) have an icon with options such as 'open in safari', 'email this page', 'copy link location', 'read later' (with something like instapaper), etc.  Bhartshorne 00:02, 7 January 2012 (UTC)
 * 31475


 * on app startup, the first thing it does is load the Featured Article. 99% of the time I start the app, I am interested in searching for a specific page, but must sit through waiting for the FA to lead before I can perform my search (all interaction is disabled while a page is loading).  This is annoying (and actually the primary reason why I started using a non-WMF wiki reader).  Please either load the cached version of the previously read page or a splash screen instead of loading a fresh article.  Note that this only happens when the app is freshly started, not when it is 'resumed' - if iOS backgrounded the app it will load to the previously viewed page. Bhartshorne 19:10, 11 January 2012 (UTC)
 * 31924