This is a brief note, at a high level about designing the GUI of an application for portability across platforms (of different screen sizes and pointer devices.) Bottom line: use context menus.
This is mostly about small, focused, document centered apps, not large, complex, bloated apps.
Skins
Skins are look and feels, or views of your app (but more than just decorations.) Use the MVC paradigm to separate the model from the view so that you can reskin your app.
Even if you don’t offer the user a choice of skin, you probably will reskin your app during its lifetime.
Skins can vary by platform. Here I mostly discuss trying to design one skin that is cross-platform.
Actions are central to reskinning. Actions are fundamental things the user can do. They are in the view, but they are linked to a method in the model. Actions in the view can be shared (without change) across many skins. For example, an action can be associated with a toolbar icon, a context menu item text, or button in a dialog.
Context menu GUI’s are cross-platform
A context menu driven app is mostly cross-platform.
A context menu is also known as a pop-up, or action sheet.
A context menu actually varies across platforms:
- phone: slides up (drawers) from the bottom (iOS), NOT at the pointer (touch)
- pad and desktop: appears at the pointer, or with a keyboard key (Win) at the selection
The notion of context is tied to the notion of selection. The context is of the object that the user designated but the object need not become a long-term selection.
An alternative to a context menu is a toolbar (toolbars are context sensitive, their contents change according to the user’s designated place in a hierarchy or place in the app.) The UI problem with toolbars is that they are away from the focus, unlike context menus. On a phone, context menus are also ‘away’ from the focus (not at the pointer), but since the screen is small, they are not far away.
Document centered apps are NOT cross platform
Many apps on desktops are document centered. Conversely, few apps on mobile platforms are document centered. This is mostly because mobile devices are used for communicating and browsing, and are hindered by sandboxing between apps.
An exception is photos as documents: most mobile devices are also cameras. Many mobile devices are photo centered: the OS supports save, open, and edit photos.
This is changing: iOS8 is beginning to support document centered with the notion of document providers.
Document centered and navigation
Mobile platforms support navigation using navigation bars (when an app has hierarchical data or nature, e.g. a music library.)
A file system having documents is also hierarchical and amenable to a navigation based UI. The problem is that on mobile platforms, the file system is not usually navigable (there is no native file browser or Finder and app files are sandboxed i.e. segregated.)
A cross-platform document centered GUI
On mobile platforms, for document centered apps, one possible navigation-based GUI comprises three paged views, where the navigation bars for the views are :
- Docs Edit>
- <Docs document Meta> where ‘document’ is the title of the current document
- <document Meta
The first view lets the user browse the app’s private store of documents (or in upcoming iOS8 apps, the private data stores of all apps that provide the mimetype which the current app understands and consumes.)
The second view lets the user edit a document, in WYSIWYG (the user sees the document.)
The third view lets the user change meta data of the document (e.g. the style or non-visible attributes.)
So, to make a cross-platform, document centered app, you use different skins:
- mobile: a skin such as the above
- on the desktop, a traditional skin having a menubar with a File menu and File Chooser dialog (instead of the first view above) and with a File>Properties or other menu item for the third view above.
Share: the OS as a clearing-house, broker for documents and apps that understand them
An OS understands what apps can publish and subscribe to document types (mimetypes.)
This is done at installation time, via resources in the app’s package:
- iOS and OSX: document icons in the bundle
- Android: ??? in the manifest
- Linux: desktop ??? in the .deb package
Mobile platform OS’s also support the notion of ‘share’, with a native dialog that shows the user which apps can understand your mimetypes. The desktops (and frameworks on top of them) don’t provide that dialog.
Sharing is broad, meaning either:
- open with another application, right now (print, or view in another application)
- send a copy to another place (a website, the cloud, or a file system)
You can see that in the iOS share dialog, separated top and bottom. Loosely, the top is ‘send to another place’, the bottom is ‘open with another application’.
Sharing is similar to drag and drop, except it crosses devices and has different syntax (order of steps): with drag and drop, both applications must be open or have an icon on the screen. So you must decide what the target is, open the applications, then sharedrag. With share, you don’t decide first; you might decide the target after you start the sharedrag. The target application need not be ‘open’ (displaying, because the mobile platforms have only one active window.)
I suspect that the notion of share will be soon supported by desktops (OS or frameworks), precisely because it would simplify the development of cross-platform apps.
Embellishing a skin with menubar on the desktop
A menubar is absent from most mobile platforms. But, an apps skin on the desktop might in addition have a menubar.
A menubar is a necessary wart on desktops: when you have many windows, the menubar tells you which window is active.
A menubar also helps a user because it might be redundant: it might include all the same actions that the context menu system does, but all in one place. A user can navigate in the menu system without navigating in the other app views.
A menubar also has global actions such as undo and redo. A notable wart of iOS is that there is an action for undo (shake) but no global action for redo (AFAIK that requires using the virtual keyboard.) Android also lacks undo/redo.
plashless 