RE: Mobile vs Desktop diferences in components

[Idylog - Nicolas Granon <ng...@idylog.com>]

In our eyes, having *components* that can run on desktop or mobile is certainly very interesting.

After all, nothing prevent us from coding listeners that will never be triggered on desktop (swipe...).
I know, I know, it will make the component heavier but not very much...
And we are seeing more and more users with laptops (i.e. "desktop" configs) AND touch screen (like "surface" devices).
As such, a "swipe or mouse-drag" component makes sense.

But we do not really adhere to the "universal **application**" concept (I am talking about RIAs, not "pages").

The fact is that mobile use-cases for RIAs do not usually match desktop use-cases. That is because usually, the user is not in the same workflow.
Mobile workflows are simpler and thus, in the end, dictate simpler UIs.
Moreover, usually, it is not the same people who use the software "in the field" (mobile) and in the office (desktop).

We have learned that the only real "universal use-case" is when someone who is supposed to use a "mobile version" of some functionality does use it on a desktop (in fact, on a laptop, most of the time). In that case, it is really the "mobile" app who adapts to a "desktop" configuration and not the other way !

We have also learned that, when this happens, people expect the "desktop" (laptop) UI to be exactly the same as the mobile UI (except maybe that they have to use a mouse instead of gestures since not everybody is provided a laptop with a touch screen).

To them, the app functionality appears to live in some kind of "mobile emulator" and that is exactly what they want !

Of course, it is quite easy to have a "mobile-designed" app (or app module) look the same on a laptop screen ! (you just have to provide both mouse-driven and touch driven event management and make sure that everything can be done in each case). You can even avoid resizing and orientation problems !

But of course this is not necessarily true for everybody...

Nicolas Granon




> -----Message d'origine-----
> De : Alex Harui [mailto:aharui@adobe.com.INVALID]
> Envoyé : jeudi 2 novembre 2017 22:52
> À : dev@royale.apache.org
> Objet : Re: Mobile vs Desktop diferences in components (Was: Re:
> Restarting contributions)
> 
> Hi Carlos,
> 
> I agree that a great goal would be to allow the development of an
> application that can run anywhere.
> 
> You are welcome to build components that can look different and
> interact differently in different environments.  Under the covers, I
> hope they are compositions of beads.
> 
> Royale components are supposed to be MVC so a gesture controller could
> replace a mouse controller for a Mobile app.  A Mobile SWC might use
> the same View bead from Basic, but have CSS that dictates a gesture
> controller instead of a mouse controller.  And that gesture controller
> would probably be in the Mobile.swc.  A SWC is a good way of overriding
> defaults since it adds new CSS selectors and rules.  Some other
> components might leverage plugins from Cordova.
> 
> To have a single app change significantly from a desktop browser to a
> mobile app, I think we would try to leverage CSS Media Query (and maybe
> extend it if we need to).
> 
> Of course, I could be wrong...
> -Alex
> 
> On 11/2/17, 2:23 PM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> 
> >Hi Alex,
> >
> >my opinion here is different, since making different libraries for the
> >same purpose make the user task more complicated.
> >For example, for the case commented of touch vs mouse we could have
> >only one button component that will use conditional compilation to get
> >mouse for desktop and gestures for mobile. If not users ends with the
> >need to create different applications for each platform, and is in our
> >hands to avoid that.
> >
> >Some cases are easy, the button case could have different
> >representations in size thanks to CSS, but others are more
> complicated.
> >Is the case of DateChooser vs DateSpinner, but I think we should get a
> >Date component that could get both behaviours depending on what
> >platform targets without the need for the user to have different
> >applications or the need of declare different components.
> >
> >Nowadays, to make an application to target different platforms and
> >devices is a nightmare, and if we make people to follow the same path
> >we have in Flex, we are not getting any improvement in that workflow.
> I
> >think Flex choose that path due to the implications already in place,
> >the mx and spark components where made before the mobile era, and was
> >not prepared for that.
> >
> >We are planning the components in this days and we could change that.
> >
> >At least, for me this would be another key factor to choose Apache
> >Royale over other solutions.
> >
> >Just my 2cnts...
> >
> >
> >2017-11-02 22:00 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> I agree that some components in Mobile.swc could be moved elsewhere
> >>and  used on desktops, but I thought there would be library of mobile
> >>components that default to different interaction models (gesture vs
> >> mouse).   Flex had some mobile-specific components (ToggleSwitch,
> >> DateSpinner, etc).  I thought their swipe interactions wouldn't work
> >>for a  desktop with a mouse.
> >>
> >> Of course, I could be wrong...
> >>
> >> -Alex
> >>
> >> On 11/2/17, 7:46 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> >> wrote:
> >>
> >> >Hi Peter,
> >> >
> >> >thanks, I think would be great to have that in mind to avoid extra
> >>efforts
> >> >for users.
> >> >As applications are wired nowadays it would be bad for us if we
> have
> >> >separate component libraries to target different devices. We should
> >> >try to make differentiations in
> >>the
> >> >components and we have
> >> >varios tools here (CSS, AS3 logic, conditional compilation,...)
> >> >
> >> >Thanks!
> >> >
> >> >2017-11-02 15:36 GMT+01:00 Peter Ent <pe...@adobe.com.invalid>:
> >> >
> >> >> (copied from another email thread; this one seems more
> appropriate).
> >> >>
> >> >> I created the Mobile kit. I did it separately because it was
> >>supposed to
> >> >> mimic how UINavigationController, UIViewController, and
> >>UITabController
> >> >> work on iOS (which I'm more familiar with than Android). But
> there
> >> >> is nothing specific in that kit (that I remember) which ties it
> to
> >> >> a
> >>mobile
> >> >> device. That's opposed to Storage kit, which is dependent on AIR
> >> >> to provide a file system on the SWF platform.
> >> >>
> >> >> I think once we look into refactoring the packages, a lot of
> >> >>Mobile could  be moved out.
> >> >>
> >> >>
> >> >> ‹peter
> >> >>
> >> >> On 11/2/17, 8:48 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >> >>Rovira"
> >> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >> >>
> >> >> >Hi, I think we should not differentiate between desktop and
> mobile.
> >>We
> >> >> >should make components ready for both platforms and
> differentiate
> >> >>desktop,
> >> >> >web, mobile or tablets mainly with CSS for sizes and in some
> case
> >>with
> >> >> >code
> >> >> >(i.e: DateChooser use to behave differently in desktop than
> >> >> >mobile)
> >> >> >
> >> >> >2017-11-02 13:29 GMT+01:00 Yishay Weiss
> <yi...@hotmail.com>:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> For now, we would like to have an Apache Royale "ViewStack"
> >> >>equivalent
> >> >> >>but
> >> >> >> we do not know where to start.
> >> >> >> What do you think the parent component should be ? Could you
> >> >> >>give
> >>to
> >> >>us
> >> >> >> some cues ?
> >> >> >>
> >> >> >
> >> >> >
> >> >> >--
> >> >> >Carlos Rovira
> >> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> >> http%3A%2F%2Fabout.me%2
> >> >> >Fcarlosrovira&data=02%7C01%7C%7Cf4ef6800329a4b7db4f608d521f0
> >> >> 21cc%7Cfa7b1b5
> >> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452237602199585&
> >> >> sdata=VJCP0F%2F%2BJ
> >> >> >Qg8fL0GOhl9VQNeocXe0y0flc2rpAYhgRI%3D&reserved=0
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fwww.codeo
> >> >scopic.com&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
> >> 8a29%7Cfa7b1b5a7b
> >> >34438794aed2c178decee1%7C0%7C0%7C636452308073997718&
> >> sdata=AoQM%2FPoQcuzZB9
> >> >A8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0>
> >> >
> >> >Carlos Rovira
> >> >
> >> >Director General
> >> >
> >> >M: +34 607 22 60 05
> >> >
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fwww.codeos
> >> >copic.com&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
> >> 8a29%7Cfa7b1b5a7b3
> >> >4438794aed2c178decee1%7C0%7C0%7C636452308073997718&
> >> sdata=AoQM%2FPoQcuzZB9A
> >> >8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0
> >> >
> >> >
> >> >Conocenos Avant2 en 1 minuto!
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Favant2.e
> >> >s%2F%23video&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
> >> 8a29%7Cfa7b1b5a
> >> >7b34438794aed2c178decee1%7C0%7C0%7C636452308073997718&
> >> sdata=GUD86EBdmMhJ9Y
> >> >zcRriunwvdGrigIefR85kK2bydDx4%3D&reserved=0>
> >> >
> >> >
> >> >Este mensaje se dirige exclusivamente a su destinatario y puede
> >>contener
> >> >información privilegiada o confidencial. Si ha recibido este
> mensaje
> >>por
> >> >error, le rogamos que nos lo comunique inmediatamente por esta
> misma
> >>vía y
> >> >proceda a su destrucción.
> >> >
> >> >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >> >comunicamos que sus datos forman parte de un fichero cuyo
> >> >responsable es
> >>CODEOSCOPIC
> >> >S.A. La finalidad de dicho tratamiento es facilitar la prestación
> >> >del servicio o información solicitados, teniendo usted derecho de
> >> >acceso, rectificación, cancelación y oposición de sus datos
> >> >dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036,
> >> >Madrid con la documentación necesaria.
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.
> m
> >e%2
> >Fcarlosrovira&data=02%7C01%7C%7Ca2066f0c8a494c8b4f5e08d522380829%7Cfa7
> b
> >1b5
> >a7b34438794aed2c178decee1%7C0%7C0%7C636452546410457380&sdata=3x5kCO6b1
> v
> >QIa
> >HMErFqYdsdtBclCZPS9fH5JP%2Bx5Few%3D&reserved=0