Multi-platform development

[Alex Tweedly]

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 
> APIs.
>
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 
https://ia.net/writer/updates/ia-writer-3

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 
over :-)
> 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.

-- Alex.