Multi-platform development

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com