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.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
