I've shared the new website at the UX team meeting today.
They think think that we should change the word "features" to "solutions" or "components".
It seems that it is hard to understand that aerogear is actually 4 different products and the word "features" doesn't reflect that.
What do you think?
On guides, there are some strange things happening on the way we structure things.
Ther is a Getting Started guides on the main index:
and there are also getting started on the iOS guides
Do you think its worth it for me to map the guides and re arrange them in a more consistent way for the new website? Like separate them per feature or per platform.
looking at andresgalante's long and scary list (
I think for the "API Documentation and Specifications", we could perhaps
break that down into two differrent things:
##Mobile SDK API Documentation (not sure about the name)
* AeroGear JS 2.0.0
* AeroGear iOS Http v0.1
* AeroGear iOS Oauth2 v0.1
* AeroGear-Push iOS 1.0.0
* AeroGear-OTP iOS 1.0.0
* AeroGear-Crypto iOS 0.2.3
* AeroGear Android 1.4.0
* AeroGear Android Auth 2.0.0-alpha.1
* AeroGear Android Authz 2.0.0-alpha.1
* AeroGear Android Pipe 2.0.0-alpha.1
* AeroGear Android Push 2.0.0-alpha.1
* AeroGear Android Security 2.0.0-alpha.1
* AeroGear Android Store 2.0.0-alpha.1
* AeroGear Cordova (lacks version?)
##Push API Docs
* AeroGear UnifiedPush RESTful APIs - stable
* AeroGear UnifiedPush RESTful APIs - development
* AeroGear UnifiedPush Java Client - Version 1.0.0
* AeroGear UnifiedPush Node.js Client (lacks version?)
* AeroGear SimplePush Java Client (lacks version?)
(yes, I removed some of the items, as I think they are not relevant in here
(see earlier email))
* Client API Proposals
* Server API Proposals
These will be hopefully soon be gone and we have, similar to 'push'
specific API Docs for Sync (client/server)
Any thoughts ?
Good morning, while reviewing some docs I started to consider to build
an AeroGear security user guide. At the same time I was wondering if
instead worth to build an AeroGear user guide with security being one of
The goal is to centralize que information in a single document. Into
this way people can read about it in ebook format or not.
Does it worth the effort?
So i have some concerns on the Current state of the conflit resolution POC that i created.
in it's current state, i had 3 methods in the api
* Read - just a GET
* Save - PUT/POST with an added "conflict" callback to handle the conflict resolution
* Remove - just a DELETE
This was all done before we wrote this spec
but even then, from the JS client perspective, it felt a lot like a pipe. In jQuery.ajax, you can actually listen for a "409".
The other thing that concerns me is that on the client side, people are using frameworks such as Ember, Angular, Backbone,etc... that have there own ways of doing server requests so i would hate to start re-inveting the wheel again.
while the read/remove don't really do anything different(they are just GET/DELETE's), the save method(PUT/POST) does. This is were all the "conflict resolution happens”. (what type on resolution algorithm, auto-merge, etc...)
I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again.
i think for node.js this might be interesting too, since we could create a piece of middleware that hooks into an express/connect request
Again, this might only be a concern on the JS client side, not sure what the other platforms are like in this regard
Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker.
But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss:
- Roadmaps should be feature specific instead of platform specific
- We should move Demos and Guides under "Get Started"
- I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them.
Now it reads: "Bringing mobile and enterprise together." is it ok?
What do you think?
Good morning my friends, I would like to ask you a favor if possible.
Include a section "requirements" in each guide on AeroGear.
Why why why? Some things are not very obvious to newcomers from other technologies, like me.
So at least the minimum about what must be
configured/instaled/dependencies would be super nice.
Thanks in advance.