YUI 3.x

[mrgrechkinn]

Hello,

When you migrate to YUI 3.x?

Regards,
Eugene

[mikeh]

I think I've answered this before, but the answer is still probably the same…

- Currently there is no business case (i.e. business benefit) to migrate to YUI 3.x.
- It would most likely involve almost a complete re-write of the Share UI.

Out of interest, why do you ask?

Thanks,
Mike

[stevereiner]

Would YUI 3.x be better for html5 mobile / touch ?

[mikeh]

Hi Steve - missed this reply until now.

Would YUI 3.x be better for html5 mobile / touch ?

Possibly, but there's much more to fix before directly targeting mobile than just throwing another JavaScript library at the app (IMHO)

Thanks,
Mike

[stevereiner]

Thanks. Would you choose YUI again for new projects?  (assuming would use new YUI version).
Over jQuery, Google Closure Library, etc. (thinking to rule ExtJS out due to its license)
For large app with both mobile and desktop  (i.e. porting FlexSpaces / CMIS Spaces, other Flex apps)
(plus PhoneGap for mobile apps)

[mikeh]

That's a tricky one to answer. I'm not convinced that targeting the same app at desktop, tablet and phone is really ever going to work that well. Our own use case analysis and research is showing that people use all three devices completely differently*. For example, just in terms of input, a mouse gives so much more precision than a fat finger, yet doesn't lend itself to the same range of gestures.

You mentioned PhoneGap; they happen to have a wiki page listing all the JavaScript frameworks that are compatible. I think I'd have to go through the same due diligence process that I did at the beginning of Share (back in 2008!) and score each library against key metrics like: maintenance & support, extendability, performance, etc. etc.

If I was writing Share again from scratch today, I'd likely have jQuery, YUI 3 and Dojo at the top of the list. I'm not sure which I'd finalise on though…

Thanks,
Mike

[stevereiner]

Thanks. Makes sense on different UI / app for different devices / uses. (What about the Binge Dining and emergency remote mobile cooking use cases?) Ideally using the same JS framework for each you can share as much code as you can.  One thing is some devices may have both screen touch and mouse/touchpad input in the future (Window 8 touchscreen laptops,  desktop PCs, Macs?)

[mikeh]

Sure, there will always be edge cases (including Power Users) that just don't fit the main model.

I think perhaps our focus has changed somewhat recently as we're concentrating on native iOS and Android clients rather than refactoring Share to be "touch compliant" (although our UX team have done some research in that area). There doesn't seem to be (or at least I haven't yet seen…) a good answer for providing a native-like web experience to users on each platform. By that I mean allowing the user to intuitively know how to use a UI control appearing on that device, having the tool- and tab-bars at the top or bottom of the screen, etc. rather than having to change mindset into "Alfresco's web mode". This might well result in more development time and managing multiple code branches, but we'd rather get noticed for great UI rather than forgotten as "not as good as the Dropbox app" for example.

Having said that, a more hybrid approach will become more pragmatic in the future. And looking at such apps as Facebook and LinkedIn there's certainly a good middle ground. I'm just not sure we're quite there yet (e.g. notice the lack of LinkedIn iPad app).

Mike