ubuntu-phone team mailing list archive

[Petko <pditchev@xxxxxxxxx>]

The problem is not scalability , anyone can resize their app , and most 
people would think of displaying less content not to look cluttered . 
The problem is that in many (if not most) cases an app that has platform 
independent functionality would need an entirely different design to 
work (nicely) . I'll give a proof-of-concept example : iOSs settings on 
the tablet [1] and on the phone [2] .

_ The main point I want to throw out there and stress on it's importance 
: _Ubuntu wants to go on all form factors . We want to be able to dock 
and get the next device in the hierarchy . But nobody thought of a 
specification for making the same apps work on all form factors 
(accordingly) .

What I think will happen : users will download a bunch of different 
applications for the same purposes (on different platforms). In the 
cases where they should use the same data (for ex. a calendar) it would 
be a mess , and in other cases Ubuntu won't show the apps inappropriate 
for this form factor (but they still would take their space ). The user 
doesn't have the ease of passage between form factors , because he'll 
have to use, most of the time, entirely different apps.

What I want to happen as a developer and a user: the perfect app for 
ubuntu (if the case is like the settings example above) would have a GUI 
spec for each form factor . I'll click the same icon on the desktop, 
tablet , phone and get the appropriate interface . Such a system should 
have it's specification (the method for Ubuntu to know which interface 
to load) , and the idea should be in the Design Guidelines .

The latter seems to me fairly simple for implementation , but I believe 
it's not entirely compatible with the "QML only" philosophy that's being 
pushed . Even so - it would be better to ship the apps in batches of n 
rewrites (for every of the n form factors) , instead of having stretched 
out or scaled down versions for the apps . I haven't coded in QML yet , 
so I don't know to what extent can functions/objects can be reused , or 
how the language overall fits with my idea , but I hope someone will 
pick it up.

Petko

[1] http://images.worldofapple.com/ios43beta2_settings.png
[2] 
http://support.eye.fi/files/2012/09/320xNxgen_settings_ios6.png.pagespeed.ic.LNpJpMzmPx.png

On 02/25/2013 12:45 PM, Calum K Pringle wrote:
> Hey guys,
>
> We are working on getting some guidance for this up on the app design 
> guides <http://design.ubuntu.com/apps> site soon as it's clearly a big 
> piece in the process for designing our apps! Essentially, consider 
> your app a touch app, which can scale (the 'how' depends on the 
> context), to different screen sizes.
>
> As an introduction, your app needs to handle all aspect ratios for 
> handling different devices and orientations (and remember a phone app 
> automatically fits in the side stage, with a flexible height either 
> 'fixed' with space below, or stretched to the full height available).
>
> So there are two main things to think about for an app to scale across 
> screen sizes and shapes;
>
> *Design a responsive layout*
>
>   * Position UI components relatively
>   * Reflow content based on space available, for example increase /
>     decrease the number of rows and columns of content
>
> *Design for responsive content*
> Consider showing more or less content, for example
>
>  1. An app in the side stage with a list of content will show more
>     content than when it is on the phone
>  2. An app on the tablet might show more information than on the phone
>  3. An app where the content is larger than what fits in view, might
>     consider showing more or less content depending on shape and
>     orientation (e.g. a map)
>
> Or, show the same content, for example
>
>  1. An app on the phone simply scales up on the tablet
>  2. A fixed height app on the phone, will maintain a fixed height in
>     the side stage
>
>
> For handling screen sizes and densities, also for asset creation, 
> please refer to resolution independence 
> <http://developer.ubuntu.com/api/ubuntu-12.10/qml/mobile/resolution-independence.html>.
> We are working on this right now, so let us know any other ideas / 
> problems you're coming across!
>
> Cheers,
> Calum
>
>
> On 24 Feb 2013, at 12:09, Matt Richardson wrote:
>
> > On 24/02/13 11:51, Dalius wrote:
> > > Hi,
> > >
> > > I would advice to preview Ubuntu Phone presentations video. The idea 
> > > is that apps not necessary should be full screen on tablet. While I 
> > > would agree that some apps (e.g. calendar, mail) should reuse full 
> > > estate, while others can be the same on phone and tablet.
> >
> > I absolutely agree. For example (in a matter close to your heart), on 
> > anything larger than a phone, the calculator should never be used 
> > fullscreen. However, for apps such as email, the full screen real 
> > estate should be used by default, certainly on up to 10" screens and 
> > potentially even larger.
> >
> > The question is that for such apps, shouldn't we try to reuse the 
> > same backend (as Petko suggested) and load different UI's? This would 
> > enable switching between phones/tablets/desktop via a "pick up where 
> > you left off" system or by docking (as demonstrated in the preview 
> > video).
> >
> > The other question is that if we have a design for such apps, should 
> > we submit it as separate phone and tablet designs, or as a single 
> > design indicating how to switch between.
> >
> > Thanks,
> > Matt
> >
> > > Regards,
> > > Dalius
> > >
> > >
> > > On Sun, Feb 24, 2013 at 1:45 PM, Petko <pditchev@xxxxxxxxx 
> > > <mailto:pditchev@xxxxxxxxx>> wrote:
> > >
> > >     I'm also very curious on that matter . Are there some specs on
> > >     how to change app behaviour or is the current style just to
> > >     rewrite the apps for a phone/tablet/desktop factor . The latter
> > >     seems suboptimal . It would be great to have 3 GUIs for the same
> > >     app backend (you download the same app, but it loads differently
> > >     under different form factors) , but as far as I know everyone's
> > >     pushing QML for writing the full apps , so there's no
> > >     abstraction between GUI<->engine .
> > >
> > >     Petko