Petko, Your idea is compatibile with "QML only" without problems. The only problem that it will be very hard to design apps like these: 4, 7 and 10 inches each require slightly different solution.
Regards, Dalius On Mon, Feb 25, 2013 at 1:56 PM, Petko <[email protected]> wrote: > 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 <[email protected]> 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 >> > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp

