As I discussed last time, the WordPress app for Windows Phone was recently updated for compatibility with the 7.5 (“Mango”) OS update. With that out of the way, I’d like to see the app undergo some UI/UX improvements to make it feel less like a ported Android app and more like a native Metro-style WP7 app.
Better and Consistent Headers
For some reason, almost every screen in the app uses a header that consists of a relatively large WordPress logo and then the typical page header text. That makes some sense for the blog selection screen (Fig. 1), but not for inner screens (Figs. 3 & 4) when the user is well-aware that they are using the WordPress app.
On the panorama screen, the blog’s name takes prime billing (Fig. 2), which makes total sense and should be replicated (with a smaller font size/height) for all other “interior” screens in the app. If the branding is still desired, we could maybe keep a small circular WP logo in the top-left or top-right corner of the screen.
For non-panorama pages, I’d also like to enable the system tray (clock, battery, wireless signal, etc.). This eats up some vertical screen space, but I think most users prefer to see it when using apps. It would also allow us to use the system progress indicator (see below).
Use Native Controls
When the WP7 app was originally made, the Windows Phone 7 SDK was pretty new and the ecosystem was relatively weak. As such, the original developer(s) was forced to implement custom controls for certain tasks, and they reverted to emulating the controls implemented/used by the WordPress for Android app. With the Silverlight Toolkit, that is no longer necessary, and it would be a great improvement to use native-like controls instead.
For comment moderation and category selection (Fig. 5), the app employs a multiple selection list control. The current design toggles a blue background for “selected” list items, where native WP7 apps like email use a checkbox paradigm. Figure 6 shows the multi-select list control from the Silverlight Toolkit.
Another Android-ism used throughout the app is progress spinners (Fig. 7). For the 1.2 release, we added a WP7-style progress bar to the panorama screen, but most other screens use a modal spinner animation. With the WP7.5 SDK, Microsoft made it super-easy to use native progress indicators by building it into the system tray.
One advantage of the spinner was that we could load the underlying page controls and they would be impossible to interact with until the spinner disappeared. If we switch to using the system-tray ProgressIndicator, then we will likely want to hide or disable controls while data is loading or an action is being performed (or whatever else is causing a progress indicator).
On the blog selection screen, you can currently delete a blog by choosing “delete blog” from the appbar menu (hidden under the ‘…’) and then choose the desired blog from a modal pop-up list. It would make a ton more sense to just support the tap-and-hold context menu paradigm as supplied by the Silverlight Toolkit. I would have the context menus contain “pin” and “delete” actions.
A similar pop-up list exists for pages and posts in the panorama, though it’s less clear that a context menu makes sense in that context. But that’s a non-issue, because…
Perhaps the biggest concession made to the WP7 app when porting it from Android was the use of the iconic panorama control. It opens to a grid of tiles for the most common actions (see Fig. 2 above), and has additional columns for comments, posts, pages, and statistics. While there is a separate “moderate comments” screen (see Fig. 4 above), the panorama is the only way to access the functionality for posts, pages, and stats.
The WP7/Metro design guidelines call for panoramas to be like “magazine covers”, with a very small amount of content that entices users to dig deeper into the content on additional screens. But the WordPress app’s panorama has heavy lists for comments (see scrollbar in Fig. 9), pages, and posts; this is not only in violation of the design guidelines, but also makes the panorama slow to load and heavy on memory usage.
Recently, I’ve been attempting to discern usage patterns for users of the various WordPress mobile apps, in addition to mobile apps for other blogging systems/services (Tumblr, Blogger, SquareSpace, etc.). As far as I can tell, the primary scenarios for mobile blog wrangling are new post creation, comment moderation, and light tweaking of recent posts.
Curiously, all of the WordPress mobile apps give equal weight to the four top-level items (comments, posts, pages, stats), perhaps because that’s what the WordPress XML-RPC API supports. But I’m in favor of optimizing the UI for the most important use-cases, and relegating some of that functionality to deeper parts of the app.
My proposal is to keep the first actions screen, but with two groups of tiles:
- “Actions”: Add a post, Moderate comments, View stats, and Blog Settings
- “Manage”: Posts, Pages, Comments, Users (once supported by XML-RPC API), <one tile for each custom post type (once they are supported by XML-RPC API)>
I would have three columns in addition to the actions screen: unmoderated comments, drafts, and recent posts. These correspond with the scenarios I identified above, and would include a maximum of 3-5 items each, with “more…” links leading to the corresponding archive management pivot screens.
Content-type management pages
This light-weight panorama would require new screens for management of the archives for each content type (page, post, comments, etc.). I envision these using the pivot control, allowing pivoting by the ‘status’ field (all/draft/published for posts, unmoderated/approved/rejected for comments, etc.).
The appbar on these pages would contain “add”, “search”, and “refresh” buttons. Tapping a list item would open an edit/moderate page for that item, and tap-and-hold would open a context menu for actions like “delete”, “preview”, “view comments”, etc. (replacing the pop-up modal menu used in the panorama now for posts and pages).
Using the new Mango SQL CE database support and paging for XML-RPC in WordPress 3.4 (hopefully), we can load the entire archive of a blog (probably only the most important fields like title, author, status, format, date, tags, and categories; notably, not the full body contents) and support infinite-scroll on these pivot pages. This would also back the “search” operation, and we could add a feature to the post editing page akin to the internal linking feature in WP core admin.
About & Feedback Page
The app currently has a page that shows when unexpected exceptions occur, and has links to some sources of help. This is a decent start, but the app really needs a proper ‘about’ page, with links to it in the appbar of the blog selection page and the panorama page.
The page would contain the current app version information and links to common sources of help and feedback, such as the official forums, official FAQ, and marketplace review form. We’ve been getting a number of bad app reviews in the past months, but not much feedback on the forums so that we can actually identify and address users’ issues.
In the last release, we added support for per-blog live tiles on the start screen. But these tiles are still static images, with nothing “live” about them. The tiles should probably update with the number of new comments, number of views today (if stats are enabled/allowed), and maybe the text of the most recent comment on the back. This will require some design work from Isaac to make it look pretty. I like the way Evernote has tackled this in their Mango release, maybe we can try something similar.
The WordPress app is painfully static, especially when compared with the first-party apps that are full of subtle animations that make the apps feel alive. The app would feel much more polished and enjoyable if we spent some time carefully designing proper animations and transitions. The Silverlight Toolkit makes transitions super easy, and animations aren’t particularly difficult either. This will require some serious design collaboration with Isaac, since it’s critical to get animations just right or else they will just annoy users and detract from the experience.
The end result of all of these proposed changes would be a noticeable change to the app’s feel and flow, which is why I’ve tagged them for version ‘2.0’.
One of the Windows Phone marketing slogans was “designed to get you in and out and back to life”. I know the WP7 team had a strong scenario-focused design effort, and it really shows when you use the OS. I’d really like to see the WordPress for Windows Phone app streamline and orient itself such that it’s fast and easy to tackle the most common tasks.
The most complex page of the app is the post/page editor, which also requires some serious rethinking. This post was too long, so I’ve saved my thoughts on the editor another post soon.