Forums

Marc, I hope I can address your concerns by referring back to the last time you revived the discussion on this topic. In that previous forum post I described our plans and we can start there as sort of a score-card to see where we are at today and our current vision and plans for the near and long future.

Back in mid-August your comments helped to bring us to officially plan for specific components, examples, and tutorials to describe and show by example how we feel someone can be successful with using YUI to develop application that work on both mobile and desktop browsers.

Since that time, we've done several key things:

* Introduce `Y.App`
* Improve the other App Framework components
* Increase our automated testing on mobile devices
* Improved Widget interactions with touch-based input[/list]



I am actively working on this, using Photos Near Me as that example application. Not only to show how to develop a rich client-side UI that runs in desktop and mobile browsers, but also how to share code between the server and client.

I've posted to the YUI Blog a few days about my experience sharing the models and templates of Photos Near Me between the client and server:
http://www.yuiblog.com/blog/2012/04/23/ ... he-server/

Also we just did an Open Hours on it yesterday where I walked through how I accomplished this by running YUI in Node.js on the server:
http://www.youtube.com/watch?v=Bjs7b8sksO4&hd=1

I plan to continue these sorts of "reporting in" on my progress as I'm developing the full tutorial which will include how Photos Near Me's responsive interface is built.



Using Photos Near Me as the example app for this tutorial will be great because it will touch on the list of issues you have here. It using view transitions, gelocation, local storage, etc.



Instead of providing controls that attempt to mimic a particular mobile OS, we are going to continue to provide some default styling for native controls, e.g. forms. In 3.5.0 we introduced our Button styles (`cssbutton`), long with a Y.Node-based button plugin, and button widget.

The plan is to continue down this road of beefing-up YUI's CSS components, including providing components which can help with RWD.



Now that Mojito is out, we are beginning the process of aligning the project with the YUI App Framework to find the right middle ground. Ideally Mojito will be using the App Framework under the hood, and provide the CLI tools, conventions, and higher-level infrastructure to provide the starting point for building an app that runs on mobile devices in the browser or in a native/web hybrid, and in desktop browsers, along with allowing code to seamlessly run on either the server or client.

It would be great to get your feedback on the implementation of Photos Near Me, and I'd be grateful if you wanted to help review the comprehensive tutorial which describes in detail how it is built and why.

Hey Eric,

Any chance on a preview of work in progress?

BTW, I have thought a lot about the question of whether widgets are important to a successful YUI mobile strategy. For what it's worth, these are my thoughts.

Ultimately, I think UI widgets divided into three types.
* Nuts and bolts
* Getting started
* Sweet and pretty

Nuts and bolts are the thing every developer needs. These are probably often supplied by the basic HTML 5 form components, but they also include autocomplete, etc. These are supplied by YUI 3, assuming the supplied widgets also work on mobile environments. Ideally, these kinds of components should use native functionality where possible and Javascript enhanced where needed.

Getting started are the things that are kind of specific to the mobile space. E.g. the typical list with arrow with each item that slides to the left when click to reveal a new page. These are the kinds of things that JQuery Mobile is good at. It provides a convenient way to create these with a kind of pseudo HTML. This stuff is not necessary per sé to develop mobile apps. In fact, commercial projects would likely not use this. However, for the guy that wants to test drive the framework or quickly develop a working prototype or simple app, this is crucial. Not having it, will IMHO limit the adoption rate of the framework in this space. Unless perhaps you manage to write some kickass tutorials or deliver some good examples with scaffolding code.

Sweet and pretty are things like Slider checkboxes, carousel views, etc. These are the things that make developers happy because they make their apps look great without effort. If these kinds of widgets are available: great! But they could be left to the gallery. However, if the gallery doesn't deliver, and I think the gallery delivers a lot of great functionality, but seldom a great *looking* widget, perhaps some open source donations from various YAHOO projects might do the trick.

Anyway, my two cents. I have a vested interest in seeing YUI be successful in this space, but unfortunately not the time to take all the speed bumps that are involved with developing stuff from scratch.

Marc

That's too bad, surprisingly a lot of people have found it very useful because it is neither too complex or too simplistic of an application.



We can always create more complex examples apps which are CRUDing to a database. Doing this will cause us to make more specific technology decisions and distract from the parts of the application that are build with YUI. I still think it is worth doing and something I'd have fun building.



Photos Near Me was build to help dogfood the components of the YUI App Framework as they were being developed. So not building it with those components doesn't make sense. And of course you could build all of it on the server, in fact I could have written the server in Java, but that's not the point with this app.

The point is to show how you can neatly organize your code by separating out the concerns of the application into discrete components and share the models and templates between the server and client.

There are a couple reasons it may seem slow:

1) It's running on Heroku which will shut down the app after a period of inactivity. Therefore the first request to come in when the app is "idling" takes several seconds for it to start back up.

2) All of the data is being fetched from Flickr's API via YQL and the Geo queries are extremely expensive:

"Geo queries require some sort of limiting agent in order to prevent the database from crying." - http://www.flickr.com/services/api/flic ... earch.html

3) I have been experimenting with using data URIs for the thumbnails that are in the HTML documents sent from the server. While this process reduces the number of initial HTTP request the browser has to make by 60 (60 thumbnails are loaded initially), it take some time to generate because it is fetching those from YQL as well.

The fact that Y.App on the client side actually makes a huge difference in performance, especially on mobile devices! The reason is that the data needed to render the `LightboxView` is already in memory in the browser, there is no trip to the server. Try it out for yourself, use the arrow keys when looking at a large version of a photo. It could never be that fast if it was hitting the search to re-render the entire page each time.



You are correct, the data the server fetched from Flickr via YQL to generate the page is serialized to JSON and embedded inside the HTML document, and some of the data is duplicated in the rendered HTML.

Having actually built Photos Near Me has lead us to internally discussions on the team about how best to transmit this initial state data from the server to the client when the server hands off control. The amount of data being duplicated in the HTML documents in Photos Near Me does not bother me, it's not much data and is way faster than re-requesting that same data from the client browser, especially on mobile devices!

How would have you architected the application differently? I would be interested to see how you could have built the app to be more efficient, easier to understand, and not use the App Framework components in YUI. I would like to make this example app better, so please feel free to fork the project and issue Pull Requests to help.

PhotosNearMe is a realistic application for Yahoo. That is a trade-of you have to consider when adopting YUI, there is a Y there. The development of the library is paid for by Yahoo and oriented towards their needs. We benefit a lot from that, but sometimes our needs diverge. I don't see many 'CRUDing' on any of Yahoo's sites so don't expect Y.App to do much about it. That is why there is so much support for YQL which, for most of us, doesn't mean much as none of our customers would pass their data through it.

YUI's data handling has never been great. There was none in YUI2 and YUI3 Model has some big shortcomings. I have long complained about that and finally decided to be more constructive and to put into the gallery my proposal (http://yuilibrary.com/gallery/show/md-model) which I admit I don't use myself since I got pissed-off with Y.App early on. (see: http://satyam.github.com/WhyGalleryModel.html for further info)

This conversation about data handling: viewtopic.php?f=18&t=4641 might probably be the longest thread in all the forum. It is Aug 18 2010! It can hardly be said that there was no interest in the subject. The conversation continued off-line invited by Luke Smith. However, after all that, all that we've got is Y.Model. Whoever wrote Y.Model (and it wasn't Luke) didn't even bother reading a single line of all that thread.

Hold on a minute, let me set the record straight here about two things: the origin of Photos Near Me, and the goals of `Y.App`.

Photos Near Me is an application that I've build on my own, and is owned and operated by me: https://github.com/ericf/photosnear.me/ ... er/LICENSE

I started the project a year ago, before joining Yahoo and before I was an official member of the YUI team. If fact, I had the original idea for the app over two years ago!

Building Photos Near Me and other applications help solidify the concepts which are `Y.App`:
-- http://yuilibrary.com/yui/docs/app/#app-component

Hopefully that clarifies things.