Alex Tweedly wrote:
> 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
Oooh - nice! I have to credit Scott Rossi for helping me (sometimes)
move past my slavish devotion to HIGs to consider broader options.
It may sound heretical to some, but I do thing Material Design is a more
useful set of conventions than the much looser guidelines Apple offers.
But even more exciting to see devs break from both to explore new
ground.
I'll read that article with gusto - thanks!
> 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.
Agreed. Such decisions need to be made *very* carefully, and ideally
after A/B user testing, time and budget permitting. At a minimum, even
the most modest budget affords the opportunity to listen to complaints
and respond to them.
>> 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.
It's probably just a failure of my own imagination, but I rather like
the complete control I have writing resize handlers.
Every other solution, no matter how it works, ultimately boils down to
responding to resize messages, just as my handlers do.
But when it's a generalized solution, it's likely to have been difficult
for its developer to guess all the possible things I might want to do,
and any generalized solution will by its nature require more lines of
code (sometimes I open GarageBand and resize its window just to remind
myself why performance in such things can be critically important <g>).
One thing that's been a godsend for me is the more recent extension to
how resizeControl works:
In older versions it was only sent in response to user interaction with
the pointer tool, but more recently it's also sent to groups when
resized by other scripts.
This allows me to keep the logic of a component's appearance internal to
itself: the card only sets the rects of a handful of groups, and the
groups take care of themselves via their behavior scripts. The group
never cares what cards it's on or where it is on the card; that's the
card's job. The group only takes care of its internals, so both the
card script and the component script are fairly independent of one another.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
