alex at tweedly.net
Tue Jan 12 13:10:34 EST 2016
Thanks for the thoughtful reply. Replies in-line
On 12/01/2016 17:02, Richard Gaskin wrote:
> Bob Warren wrote:
> > Hi Alex,
> > The lack of response to your question shows, I think, that multi-
> > platform apps in LiveCode, for both desktop and mobile, are really
> > hard to achieve.
> In all fairness, his post was unattended for just 22 hours.
> I pondered replying myself yesterday when I first saw it, but it is
> indeed a tricky goal, something very few people in all the world even
> attempt, in any language.
> While it's true that Ubuntu and more recently Microsoft have begun
> exploring convergence strategies for a single adaptable, scalable set
> of UI conventions across all device types, the reality is that to date
> neither has been enormously successful (though the night is young, and
> the research and APIs still in early days).
Indeed. In fact I bought a Surface Pro last month, and after one day I
abandoned it (early enough to give it to someone else as a Christmas
present - he said, knowing they will never read this list :-) It was
(for me) just unusable because of the tiny buttons and icons (or you
could scale them up, and make it unusable because you couldn't fit any
more text etc. on it than I could already get on a mid-size tablet)
> Apple still has the belief that every category of devices require
> their own unique OS, with their own interaction models and supporting
Yes, but at least they are willing to accept apps which don't. One that
has heavily influenced my views is iAWriter - an app which I find a joy
to use (on iPad). It has eschewed the iOS UI guidelines almost
completely, in favour of what feels much like desktop menus. And even
better, they've written about the choices they made, and why - see
In particular, to quote one short section:
[ on iOS ]
> We eliminated arbitrary icons, and streamlined the labelling and
> grouping of functions. After a lot of iteration, we ended up staring
> with disbelief as a desktop app’s menus emerged. Menus were invented
> in a time of small screens. With the return of small screens they
> actually make a lot of sense.
[ ... lots of good stuff from Richard omitted for brevity ....]
> Now that I'm building multi-device-type apps, for myself I find it
> easier to make separate layouts for phone and desktop, allowing each
> to take best advantage of what the device and its input models offer.
> I tend to build things with reusable behavior-driven groups, which
> allows me to have a toolbar common to iOS and Android but placed at
> the top for Android and the bottom for iOS, as each HIG suggests.
> The toolbar for desktop not only has more space but more importantly
> supports in some cases different tasks, because the device type serves
> a different set of use cases.
Ummm. I am very wary about this differentiation. I think we can
over-categorize the ways users *might* want to use different devices. I
would dearly love to be able to travel with just my phone and a tablet
(either 7-inch android or iPad Pro, depending on many factors), and
leave the laptop behind. But if (as happens all too often) the developer
has decided that some things won't be needed on limited devices, I find
myself precluded from leaving the laptop behind because some
more-complex task would be "clumsy" on a limited screen. OK - let it be
clumsy, I'll accept that and put up with it for the sake of being able
to do it at all.
Trivial (similar) case - iOS calendar app which *insists* on going into
a particular mode (weeky? hourly?) whenever I turn it into landscape
orientation. !? OK, I understand that orientation handles this mode
better than portrait does, and this orientation doesn't handle the other
viewing modes as well - but please leave that as my choice. (OK, rant
> The card controls the layout of the groups within it, so a different
> card for mobile, tablet, and desktop lets me optimize the layout for
> what the user could expect to do for each, and since the underlying
> business logic is the same for all very little of my central libraries
> are affected by whichever UI happens to be in use at a given moment.
Good idea. A single app (and hence single main stack), but with
different cards is an approach I hadn't particularly thought about. Thanks.
> There are many ways to solve such problems, and the way I find useful
> for me in making productivity apps will no doubt differ from others,
> and certainly differ a lot from those making games where the UI and UX
> are very, very different.
> But in all cases I believe two things:
> 1. Making software is by its nature inherently complex, requiring
> study and more than a little typing. LiveCode makes it far
> less difficult than most tools, but I doubt making good software
> can ever be truly "simple".
> 2. We can learn from the world of responsive web design to reinforce
> best practices with native app development: factoring code, data,
> and UI to minimize interactions between them and thereby maximizing
> flexibility across device types.
I think this second point reinforces what was said earlier today on
another thread about the need for a better, more modern, approach to a
*built-in* geometry manager / helper which can make it easier to
implement responsive, variable UI layouts. I don't think it needs to be
a (totally) IDE-based - it's just fine to write some script to deal with
more complex cases - but it should make it easier.
All suggestions welcome - in the meantime I'll push ahead with the
outline version of my app, making as much of it as I can be separated
into libraries, behaviours, etc., and (with luck) will be able to make
the multiple apps vs multiple cards vs multiple layouts decision be as
unimportant as possible.
More information about the Use-livecode