[Mono-dev] Portable phone apps

[Jonathan Pryor]

On Tue, 2010-02-23 at 22:45 +0000, James Mansion wrote:
> Jonathan Pryor wrote:
> > It will instead be "write the core once, write the UI once for each
> > target platform," as (currently) the UI layers are platform specific
> > (Silverlight for Windows Phone 7 Series, MonoTouch for iPhone, and
> > MonoDroid for Android [0]).
> >   
> Is it not the case that Mono could provide a silverlight and XNA 
> implementation on those platforms though?

Yes.  That doesn't mean that they should be used.

XNA is for games, so I won't discuss it further. :-)

The problem with Silverlight, while a nice API and visually pleasing, is
that it isn't the system UI, nor can it be.

The result is something akin to writing a UI in Flash: it works
everywhere, BUT it looks the SAME everywhere, with it's own style for
e.g. buttons, lists, text entry, etc. which will NOT match the rest of
the platform.

This is often considered acceptable because it's either for games (where
custom UIs are the norm) or some other task-specific program where
having a custom UI isn't particularly problematic.

This doesn't mean that it's good for users, especially inexperienced
users who don't want to think much (which should be most users -- I
certainly don't want to think too much when using an app).  For user
simplicity, you WANT a UI which looks like all the other apps, behaves
like all the other apps, uses the same UI conventions and idioms.  Every
place where the UI differs is a place that will potentially trip up a
user.

For example, "navigation-based" iPhone apps usually have a button bar
across the top to allow navigating to the previous page.  Suppose, for
the sake of argument, that a particular app wanted the user to tap the
screen with two fingers to go to the previous page instead of using the
button bar.

This may be "good" (it leaves more space on the screen for
non-navigation UI elements), but it's not easily discoverable, most
people don't know about the "two-finger tap" (it's not a common
interaction mechanism), and thus works counter to having a user-friendly
app.

Similarly, Android convention is to use the hardware back button instead
of having an app-specific UI button.  I doubt that Android users would
be pleased to see a UI back button -- it's counter to their conventions.

Consistency is #1.

All of which is to say that a Silverlight UI on iPhone, while
technically possible, is NOT always going to be appropriate, and NEVER
WILL BE always appropriate for an iPhone UI.  It WILL look foreign, it
WILL behave foreign, and it WILL confuse some set of users.

(The same argument holds for every other platform -- users always expect
apps to follow the platform's UI conventions, and any app that violates
those conventions is subject to user complaint or non-use.)

Which is why I've argued for years that the best UI for users is a
platform-specific UI, for all target platforms, NOT a "one size fits
all" UI (which is certainly easier for the developer to write).

 - Jon