Fwd: Website restructure
by Erik Jan de Wit
Hi,
What I get from this thread is that we like the colour section idea, but we don’t want to re structure the entire site. So what we need to discuss is how are we going to use these sections if we don’t restructure. What I like about them is that it emphasises that our API’s are similar for all platforms and that we only have one document explaining for instance what pipes are. But the menu, doesn’t fit into this new colour scheme, so we need some decisions about how we are going to move forward.
Based on the work Corinne did with the introduction of sass I’ve had a go at implementing a bit what Hylke proposed, have a look at my sass branch https://github.com/edewit/aerogear.org/tree/saas and the page I’ve updated http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ to be in section layout. Don’t look at the header and footer as I haven’t changed those.
There are a couple of things that I don’t like about the current implementation, to enable the code blocks I’ve added some html into the asciidoc and some jquery magic in the layout. Maybe we could make this better by chaining the rendering/backend or by introducing some sort of plugin into asciidoc? Other then that, I’m sure Hylke sees a lot of things that are still off, but it’s a start.
What do you think?
Cheers,
Erik Jan
p.s
example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff
10 years, 2 months
Website restructure
by Corinne Krych
>
> @Hylke see my comments below
>>
>> On 24 Jan 2014, at 19:08, Hylke Bons <hbons(a)redhat.com> wrote:
>>
>>> Hey,
>>>
>>> On 24/01/2014 14:58, Corinne Krych wrote:
>>>> Hello All,
>>>>
>>>> I’ve being working on sass branch [1], the same branch Erik-Jan did its initial work.
>>>> Here is more feedback on our site redesign
>>>>
>>>> 1. Example page with each language code snippet
>>>> It’s a good idea, to show the unified aspect of our libs. Having a short snippet code is great, however it’s not possible to fit the detailed example we alreday have in our documentation. Rather than simplifying and not going into details, I think we could have a main page like [2] which give the definition + each snippet. Below the code snipet I’ve added a link:
>>>> Read more on Pipes on Android / Pipes on iOS / Paging on Web
>>>> which points to detailled page.
>>>>
>>>> I think we should keep this documetation. It goes deeper in the sample code as opposed to snippet which is not necessarly complete code. One think that we could do is use code sample extracted from our cookbook recipe. So we can point to the repository for the full app code.
>>>>
>>>> @Hylke Do you have a better idea than just a simple link? I think it’s not visual enough. And what should be the layout of the detailled example page?
>>>
>>> The [2] link is on localhost. :)
>>>
>>> How about we try it out for Pipes and see how it goes? Yes, we probably
>>> would need to move some stuff out to other sections, but that's ok.
>>> We'll have a better ideas what to do with the "excess" docs once we try
>>> any simplify the multiple documents into one.
>>>
>>> Here's the idea for the scopes I had:
>>>
>>> - Examples => High level overview of AeroGear concepts and code snippets
>>> about how they're used. Not neccesarily big programmes.
>>> - Documentation
>>> - Getting started => Download and setup
>>> - API Browser => just a link to the full API overview
>>> - Guides: We can go more all out here. Tutorials, example projects, more
>>> complex configurations, etc. Basically everything else that doesn't fall
>>> into the above categories. :)
>>>
>>> I know it's a lot of work... I do think it's the best way to go. I'd be
>>> happy to help out on this too, though I've absolutely no clue on the
>>> topic, but that may actually be a good thing for explaining stuff to
>>> people new to the concepts. :)
>>>
>>
>> Actually if you setup the sass batch link[1], you run your environment and then you go to link[2] loclhost as it’s running on our instance, you will see i’ve tried it out for Pipes. In order to do it i needed to split the documentation for iOS/Android (I haven’t done completely JS part). with this exercice what i understand is:
>> 1. the first view should contain code snippet with shows the unified aspect of client lib. those sippet are not complete code, it should be simplified.
>> 2. this simplified view is not enough for a developer. Selecting his platform tab, he will be redirected to android for ex complete description on Pipes. Ideally this description is based on a cookbook exemple.
>> 3. if the developer want to test it himself he’ll have the option to download the complete sample code (github link to cookbook repo) and just run it
>>
>> So the explantion goes through 3 layers from 1)high level description (cross platform), 2) detailled explanation linked to a platform to 3) sample code implementation (obvious linked to a platform).
>>
>> My question is How to make the transition from 1) to 2) ? See picture below
>>
https://www.dropbox.com/s/tz25vzu8doh6jkk/agorg2.png
>
>
>>
>>>
>>>>
>>>>
>>>> 5. Dracula theme vs White theme
>>>> If you uncomment [3] you can have a white theme. A shame that with Dracula theme we loose the AeroGear blue and orange logo...
>>>> @Hylke for the dracula theme we need AG logo in each of the 3 colors.
>>> Yes, I'll send you those. Don't worry about the theming too much, as we
>>> haven't really discussed that yet. The "Dracula" theme was more of an
>>> example of how we can use colours to mark different sections of the
>>> project/site. So if you'd like to see things different, let me know! :)
>>>
>>>> 5. Menu
>>>> @Hylke you said you want to remove the actual menu, but what do you propose to navigate between topic: Core/Security/Push/Sync
>>> I've actually added it back in the mockup (see the other email on the
>>> thread). It was more of a time thing that I hadn't added it yet. It's
>>> back now.
>>>
>>> Hylke
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
10 years, 2 months
bower repos for custom builds
by Lucas Holmquist
so i created this JIRA https://issues.jboss.org/browse/AGJS-133
It would kind of neat if we offered some custom builds in bower,
this way it could make it super easy for someone to pull in just data manager for example
$ bower install aerogear-datamanager
each "custom" build would be in it's own repo, but they don;t have to be "aerogear" repos, similar to how the bower ember repo isn't actually an ember official repo
wdyt?
would be somewhat easier to get "new" features out without waiting on the official release
10 years, 2 months
Sync Day 3 Sync takes Manhattan
by Summers Pittman
I rolled up the feedback to the email I sent yesterday.
One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is
probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to
order things and break out big "chunks" which will need to be done and
the approximate order they should be done in while also drawing a line
around what features we have. This is why I have not placed ANY
versions YET. By the end of today/tomorrow morning I hope that we will
be in a good place to do that.
Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener
Upgrading)was merged into M3(Push Listeners) so that we can have
optional push sooner.
# M1 - Basic revision Control, Data Model, Change Management, Server <->
Client Contract
* We seem to be in agreement on a basic set of metadata to be kept for
each object. [objectId, revision, object].
* We should have a basic server definition which supports CRUD and
keeps our revision numbers in check. This may not be a server product
but just a spec that can be implemented by anything at this point.
* We should have basic client code which keeps up with revisions, can
check the server for new revisions, and alert the user if there is a
sync conflict.
M2 - Sync Listener w/ Polling based sync listener, conflict management,
* We define on the client how callbacks will work for alerts when
remote data changes
* We implement a listener which polls a data source and delivers
changes to the user.
* We define how conflicts are managed
M3 - Push based Sync Listener, Sync Listener Strategy Management
* The client and server will negotiate when it is appropriate to
switch between polling, push, and realtime sync strategies.
* We will build on our previous Listener work from M2 to include a
Push listener that the server can speak to.
* We will support ways of automagically managing sync listeners based
on the availability of Push.
M4 - Server user management, Network Management, Server side session
management
* We will define in the client how network state and sync state
interact. IE how to handle errors in fetching new data when the
Listener is alerted. (Exponential back off, retry, etc)
* The server will need to have some mechanism for managing user
"sessions". This is what users are actively being synced.
* The server should have a basic authentication and authorization plan
for controlling how data is synced
M5 - "Real Time" Sync Listener. Bidirectional automatic sync
* Instead of using push, Realtime Sync uses something like web
sockects. to automatically sync local and remote data.
* Previous Sync listeners may have to be upgraded to include "upload"
abilities.
* We will also include the ability to switch between Realtime sync
listeners, polling listeners, and push listeners
* The server will need to support this as well.
M6 - Conflict resolution, Error detection and support
* Provide a more comprehensive strategy for managing conflicts.
* Provide some automated conflict resolvers
* The server could get a larger set of conflict and errors messages
M8 - Party
* We have a sync party.
10 years, 2 months
