Hey everyone, I'm currently trying to wrap my head around a lot of AeroGear and JBoss technologies, so I spent some time rearranging/rewording things that weren't very clear to me on the aerogear.org home page. At first as an excercise to get a better understanding about AeroGear myself, but I think everybody will benefit from having easier to understand home page content. I've rearrange some parts to create a better flow without removing any of the current content. Here are the most important changes: - Stick to one paragraph per "topic" - Add action link below each paragraph to more resources - Add links to Wikipedia pages for certain acronyms, as not everybody may be familiar with all the acronyms used (even experienced developers) - Expand certain acronyms to their full meaning Let me know what you think needs improving/adding/removing (or please correct things that I got wrong), and if this could potentially be intergrated to the site. Feedback appreciated! Thanks, Hylke ----------------------------------------------------------- = Bring Mobile and Enterprise together! = *** AeroGear let's Android, iOS, and (hybrid) web apps talk to your JBoss Aplication Server. ***

Get started with a library for your platform…

[[---platform buttons here---]] == Why? ==

=== Unify mobile development === AeroGear provides flexible and extensible libraries to simplify mobile development across platforms and cut common repetitive infrastructure tasks. Integrate with the most exotic of endpoints. [[ Get started >> ]]

=== Simple API === Talking to [[ RESTful ]] (1) backends couldn't be easier. We've abstracted all of the plumbing into a simple programmatic API for doing [[ CRUD ]] (2) operations and paginating large amounts of data. [[ Browse API documentation >> ]]

=== Mobility and security, both === Integrate with your existing enterprise environment. AeroGear provides Two-Factor Authentication and One-Time-Password features to improve your application's security. [[ Learn about AeroGear Security >> ]] === Easy server routing === Define HTTP routes with a simple Java Internal [[ Domain-Specific Language ]] (3). The perfect fit for client-heavy applications where you have very few entry points and delegate logic to the client tiers. [[ Learn about AeroGear Controller >> ]]

------------------------------------------------------------ (1) http://en.wikipedia.org/wiki/RESTful (2) http://en.wikipedia.org/wiki/Create,_read,_update_and_delete (3) http://en.wikipedia.org/wiki/Domain-specific_language _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hey Kris, On 24/05/2013 18:40, Kris Borchers wrote: > We are not specific to any back end so we won't mention JBoss here. >> Get started with a library for your platform… > Is that line really necessary? Right now, it's not very clear where these buttons will take you. Visitors can find out, but it's friendlier to point out where you're going to be taken in advance. "'Javascript', 'Android' what?".

>> [[---platform buttons here---]] >> >> == Why? == > Again, is this necessary? What does it add? Both of those lines add more vertical scroll on mobile devices so I don't see the benefit, if any, outweighing that. To transition from the "What is" section to the "Why you should care" section. It's not strictly necessary, but I like some kind of transition between sections.

It does add a few pixels of vertical space, but this is something we should look at from a higher level. There are many elements that take a lot of vertical space currently, so I'd like to keep the discussion on the functional level instead of going into the details of scale or pixels. We can make CSS tweaks later on as well if a certain vertical height is a requirement.

>> === Unify mobile development === >> >> AeroGear provides flexible and extensible libraries to simplify mobile >> development across platforms and cut common repetitive infrastructure >> tasks. Integrate with the most exotic of endpoints. >> [[ Get started >> ]] > Where would this link go? We have multiple paths for getting started, thus, the platform buttons at the top. To "Get the gear" or a page that is a little bit more in between a download page and a first run tutorial (I don't think this exists yet, but I'm happy to take that on as well).

>> === Simple API === >> >> Talking to [[ RESTful ]] (1) backends couldn't be easier. We've >> abstracted all of the plumbing into a simple programmatic API for doing >> [[ CRUD ]] (2) operations and paginating large amounts of data. >> [[ Browse API documentation >> ]] > Which set of API docs? Each platform has their own, again, we have the buttons at the top. This goes to the API Docs page that's already in present in the top menu. There can be more entry points to the same thing. Maybe it's a filler, but it's good for consistency to let every paragraph be followed by a link. I'm open to any other links if you can think of something better.

Thanks, Hylke >> === Mobility and security, both === >> >> Integrate with your existing enterprise environment. AeroGear provides >> Two-Factor Authentication and One-Time-Password features to improve your >> application's security. >> [[ Learn about AeroGear Security >> ]] >> >> === Easy server routing === >> >> Define HTTP routes with a simple Java Internal [[ Domain-Specific >> Language ]] (3). The perfect fit for client-heavy applications where you >> have very few entry points and delegate logic to the client tiers. >> [[ Learn about AeroGear Controller >> ]] >> > I will leave security and controller comments to Bruno and Dan. These changes would also probably require imagery changes as well. >> ------------------------------------------------------------ >> (1) http://en.wikipedia.org/wiki/RESTful >> (2) http://en.wikipedia.org/wiki/Create,_read,_update_and_delete >> (3) http://en.wikipedia.org/wiki/Domain-specific_language >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hey Kris, Ok, it seems that we're mostly on the same page on this. You are right that the main line about AeroGear+JBoss doesn't make sense when keeping other implementations of backends in mind. Do you have any other suggestions? Perhaps "server" or backend"? I think we have to be careful to be too generic as well though, as these terms can mean anything. That said, I do think there's a role to play for JBoss AS as an example implementation (and probably something that a lot of people would use). We could put it somewhere lower on that page?

For anyone following up on this: it's mostly about the content, I wouldn't worry too much about how things are going to look in the current layout as the CSS can be changed easily to accomodate (and I'm happy to take this on or help out). Thanks, Hylke On 24/05/2013 20:15, Kris Borchers wrote: > On May 24, 2013, at 2:01 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > >> Hey Kris, >> >> On 24/05/2013 18:40, Kris Borchers wrote: >>> We are not specific to any back end so we won't mention JBoss here. >>>> Get started with a library for your platform… >>> Is that line really necessary? >> Right now, it's not very clear where these buttons will take you. >> Visitors can find out, but it's friendlier to point out where you're >> going to be taken in advance. "'Javascript', 'Android' what?". > I can agree that something is needed but still not sure if I like that sentence fragment floating there. >>>> [[---platform buttons here---]] >>>> >>>> == Why? == >>> Again, is this necessary? What does it add? Both of those lines add more vertical scroll on mobile devices so I don't see the benefit, if any, outweighing that. >> To transition from the "What is" section to the "Why you should care" >> section. It's not strictly necessary, but I like some kind of transition >> between sections. > Again, I'm not sure how I feel about a little piece of text just floating in the page but I am willing to go along with it and see what you come up with. >> It does add a few pixels of vertical space, but this is something we >> should look at from a higher level. There are many elements that take a >> lot of vertical space currently, so I'd like to keep the discussion on >> the functional level instead of going into the details of scale or >> pixels. We can make CSS tweaks later on as well if a certain vertical >> height is a requirement. > Agree >>>> === Unify mobile development === >>>> >>>> AeroGear provides flexible and extensible libraries to simplify mobile >>>> development across platforms and cut common repetitive infrastructure >>>> tasks. Integrate with the most exotic of endpoints. >>>> [[ Get started >> ]] >>> Where would this link go? We have multiple paths for getting started, thus, the platform buttons at the top. >> To "Get the gear" or a page that is a little bit more in between a >> download page and a first run tutorial (I don't think this exists yet, >> but I'm happy to take that on as well). > If you are willing to dive in on a page like that I think we would all appreciate it. Otherwise, Get the Gear is probably ok too. >>>> === Simple API === >>>> >>>> Talking to [[ RESTful ]] (1) backends couldn't be easier. We've >>>> abstracted all of the plumbing into a simple programmatic API for doing >>>> [[ CRUD ]] (2) operations and paginating large amounts of data. >>>> [[ Browse API documentation >> ]] >>> Which set of API docs? Each platform has their own, again, we have the buttons at the top. >> This goes to the API Docs page that's already in present in the top >> menu. There can be more entry points to the same thing. Maybe it's a >> filler, but it's good for consistency to let every paragraph be followed >> by a link. I'm open to any other links if you can think of something better. > Duh, that makes sense. Main API docs index is fine. >> Thanks, >> >> Hylke >> >>>> === Mobility and security, both === >>>> >>>> Integrate with your existing enterprise environment. AeroGear provides >>>> Two-Factor Authentication and One-Time-Password features to improve your >>>> application's security. >>>> [[ Learn about AeroGear Security >> ]] >>>> >>>> === Easy server routing === >>>> >>>> Define HTTP routes with a simple Java Internal [[ Domain-Specific >>>> Language ]] (3). The perfect fit for client-heavy applications where you >>>> have very few entry points and delegate logic to the client tiers. >>>> [[ Learn about AeroGear Controller >> ]] >>>> >>> I will leave security and controller comments to Bruno and Dan. These changes would also probably require imagery changes as well. >>>> ------------------------------------------------------------ >>>> (1) http://en.wikipedia.org/wiki/RESTful >>>> (2) http://en.wikipedia.org/wiki/Create,_read,_update_and_delete >>>> (3) http://en.wikipedia.org/wiki/Domain-specific_language >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi Hylke, I'm not sure if I'm completely understanding your question. But the main concern on AeroGear is to make our implementations portable between serveral backends for example: Node.js (https://github.com/abstractj/todo-aerogear-node), Ruby (https://github.com/abstractj/todo-aerogear-sinatra), Java with JBoss, Python (like summers did).

I don't think our main page must be tied with any kind of specific backend. JBoss is our first class citizen, but mobile is not tied to the backend, for this reason we do not mention JBoss at the main page. Makes sense? Hylke Bons wrote: > Hey Kris, > > Ok, it seems that we're mostly on the same page on this. > > You are right that the main line about AeroGear+JBoss doesn't make sense > when keeping other implementations of backends in mind. Do you have any > other suggestions? Perhaps "server" or backend"? I think we have to be > careful to be too generic as well though, as these terms can mean anything. > > That said, I do think there's a role to play for JBoss AS as an example > implementation (and probably something that a lot of people would use). > We could put it somewhere lower on that page? > > For anyone following up on this: it's mostly about the content, I > wouldn't worry too much about how things are going to look in the > current layout as the CSS can be changed easily to accomodate (and I'm > happy to take this on or help out). > > Thanks, > > Hylke > > > On 24/05/2013 20:15, Kris Borchers wrote: >> On May 24, 2013, at 2:01 PM, Hylke Bons&lt;hbons(a)redhat.com&gt; wrote: >> >>> Hey Kris, >>> >>> On 24/05/2013 18:40, Kris Borchers wrote: >>>> We are not specific to any back end so we won't mention JBoss here. >>>>> Get started with a library for your platform… >>>> Is that line really necessary? >>> Right now, it's not very clear where these buttons will take you. >>> Visitors can find out, but it's friendlier to point out where you're >>> going to be taken in advance. "'Javascript', 'Android' what?". >> I can agree that something is needed but still not sure if I like that sentence fragment floating there. >>>>> [[---platform buttons here---]] >>>>> >>>>> == Why? == >>>> Again, is this necessary? What does it add? Both of those lines add more vertical scroll on mobile devices so I don't see the benefit, if any, outweighing that. >>> To transition from the "What is" section to the "Why you should care" >>> section. It's not strictly necessary, but I like some kind of transition >>> between sections. >> Again, I'm not sure how I feel about a little piece of text just floating in the page but I am willing to go along with it and see what you come up with. >>> It does add a few pixels of vertical space, but this is something we >>> should look at from a higher level. There are many elements that take a >>> lot of vertical space currently, so I'd like to keep the discussion on >>> the functional level instead of going into the details of scale or >>> pixels. We can make CSS tweaks later on as well if a certain vertical >>> height is a requirement. >> Agree >>>>> === Unify mobile development === >>>>> >>>>> AeroGear provides flexible and extensible libraries to simplify mobile >>>>> development across platforms and cut common repetitive infrastructure >>>>> tasks. Integrate with the most exotic of endpoints. >>>>> [[ Get started>> ]] >>>> Where would this link go? We have multiple paths for getting started, thus, the platform buttons at the top. >>> To "Get the gear" or a page that is a little bit more in between a >>> download page and a first run tutorial (I don't think this exists yet, >>> but I'm happy to take that on as well). >> If you are willing to dive in on a page like that I think we would all appreciate it. Otherwise, Get the Gear is probably ok too. >>>>> === Simple API === >>>>> >>>>> Talking to [[ RESTful ]] (1) backends couldn't be easier. We've >>>>> abstracted all of the plumbing into a simple programmatic API for doing >>>>> [[ CRUD ]] (2) operations and paginating large amounts of data. >>>>> [[ Browse API documentation>> ]] >>>> Which set of API docs? Each platform has their own, again, we have the buttons at the top. >>> This goes to the API Docs page that's already in present in the top >>> menu. There can be more entry points to the same thing. Maybe it's a >>> filler, but it's good for consistency to let every paragraph be followed >>> by a link. I'm open to any other links if you can think of something better. >> Duh, that makes sense. Main API docs index is fine. >>> Thanks, >>> >>> Hylke >>> >>>>> === Mobility and security, both === >>>>> >>>>> Integrate with your existing enterprise environment. AeroGear provides >>>>> Two-Factor Authentication and One-Time-Password features to improve your >>>>> application's security. >>>>> [[ Learn about AeroGear Security>> ]] >>>>> >>>>> === Easy server routing === >>>>> >>>>> Define HTTP routes with a simple Java Internal [[ Domain-Specific >>>>> Language ]] (3). The perfect fit for client-heavy applications where you >>>>> have very few entry points and delegate logic to the client tiers. >>>>> [[ Learn about AeroGear Controller>> ]] >>>>> >>>> I will leave security and controller comments to Bruno and Dan. These changes would also probably require imagery changes as well. >>>>> ------------------------------------------------------------ >>>>> (1) http://en.wikipedia.org/wiki/RESTful >>>>> (2) http://en.wikipedia.org/wiki/Create,_read,_update_and_delete >>>>> (3) http://en.wikipedia.org/wiki/Domain-specific_language >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev