The AeroGear project had it's official launch last week and I want to review what we're doing and where we're headed. For starters, AeroGear is focused on:

• Education - Screencasts, Tutorials, and Quickstarts for running any (HTML5, Hybrid, Native) mobile solution with JBoss projects and app servers.
• Innovation - Many of AeroGear's primary goals are to provide HTML5 extensions for web applications, both mobile and desktop based.
• Community - We already have several community members contributing examples, demos, and other useful resources. We want to hear from you! We're here for the community.'

Most front-end developers are familiar with "jQuery callbacks and RESTful services", but all developers should be familiar with how this architecture affects their end of the stack. So we put together the following diagram which explains the concept of "POH5" (Plain Old HTML5)

So why another acronym? Why not just call it "Plain Old Open Web"? The HTML5 revolution causes developers to think differently about their overall architecture, with more JavaScript and CSS on the client-side and RESTful endpoints on the server-side. AeroGear hopes to bridge this gap and provide the tools or "gear" you need to get started quickly with the best possible solution.

We're just getting started... For now, we have a quickstart application which fully examines each piece of the POH5 architecture. Take it for a spin with the live demo.

Join Us! or come hang out on freenode #aerogear.

So I made it over the hump of this mobile design week of madness. Below you will find a dark theme with a component skin for the rich:accordion component.

Day 3: About The Design

Here we have another phone based design broke out into 3 pages.
The first page is a standard menu so not much to say there. The bottom menu bar is a little different from my first design – following the lead of the native twitter iPhone app.

As you can see with the second page (below), this is not a standard accordion panel type of component. When you touch an option from page one, the accordion expands on a different page and only focuses on that specific panel. Not sure if it could work, but accordion collapse/expand style of components don‘t make a ton of sense to me on limited screen real estate.

So after you go through the menu options and decide on a component, you are taken to the detail/demo screen(below) where you can play around with your component of choice.

Note the small orange page marker dots at the bottom. The user would have the ability to flip through each component in the given section by swiping horizontally.

Day 2 of the RichFaces skinning and we have the first approach for tablet devices. Tablets are a little harder to design for because of a few reasons:

1) Your design sits on the fine line between desktop and mobile. You are designing your app for a max 1024 pixel resolution (in landscape mode) but you must also take advantage of mobile usability (which you will see in page2)

2) Similar to the iPad Mail.app, it‘s almost like you are designing 2 different UI‘s for landscape and portrait modes. For portrait you need more drop down menus, and for landscape you can try to fit everything on one page without the drop downs.

Day 2: About The Design

Here we have the interaction broken out into 2 pages. The first page shows the primary menu and isn‘t all that exciting.

Notice how, unlike the iphone design from Day 1, I left the browser button overrides within the app itself. Tablet web apps are completely use case driven so this will vary. But since we have so much more real estate, we can play around with standard navigation options that keep the user's attention focused on the app itself.

The second page is what you see after selecting a menu item from page 1 (click to enlarge). Here we have the title bar at the top left with a built in back button which takes the user back to the first screen.

To the right of the title you see the secondary menu represented by rounded rectangles. Next is the main content of the page broken out into content and actionable panels.

And finally you have the big arrows to the right and left. These arrows are “thumb reachable” which is a common usability pattern in portrait mode tablets. It provides an easy page flip access to all of the RichFaces components within the top level category.

The great thing about CSS3 transitions is that you can really make a UI like this scream and flow seamlessly. So you can imagine how tapping an arrow with your thumb will slide in a new component demo and gracefully highlight the secondary menu option at the top.

So this concludes our design for Day 2. As I said earlier, this is more of a use case driven design. WE could spawn a very minimalistic skin and component look and feel from this. However, It would be more to display the power behind RichFaces ajax and templating features as the user moves through the app.

Today marks an important day in the RichFaces project as we continue to head down the mobile web road. Since we have such a great community of users and followers, we want you to be involved with the design process.
So each day this week, I will come up with a new proposed design/theme for RichFaces Mobile and we want to hear your feedback.

I will announce each new design (both for tablet and phone) via twitter with a link back to this article. I will try my best to pick apart each design and describe why I did what I did, and hope you can give me some real world feedback. We want this project to actually make sense and be usable to what you guys are facing in the real world. Without further adieu....

Our first task is to tackle the RichFaces showcase of components. Classifying what is mobile ready and which components may need a little work.

Day 1: About The Design

Here we have what could be the RichFaces component showcase skin. This is what I will be posting a new version of each day this week.

In this design we have the standard browser “functionality take over” at the top header. The custom back button is essential to mobile web design and must be overridden here – following the pattern of previous designs.

Nothing too different about the standard menu options and detail options (center stage). Following convention here as well. One thing I am adhering too are the usability guidelines set forth by Jakob Nielsen‘s Usability of iPad Apps and Websites

To get the full tab bar at the bottom (and to replicate the native feel) the user must bookmark the application. I think it makes sense for this menu to be contextual to the app and provide other alternate routes.