4:24 p.m.
Hey everyone,
So Jay asked me to look at how the website content is structured and how
to improve it. Since we have so much content, it gets confusing very
quickly.
https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
Here's a mockup of a possible solution. I'm better at explaining things
in pictures than in words, so please have a look. I'll explain things in
more detail below.
I've tried to keep every subproject use case based, and explain the use
case before features. See this as a bigger picture, and don't focus on
the graphic design too much, it's there to help explain the structure of
the project, and is not necessarilly a final graphical design in any way
(though if you like it we can make it work!), but I wanted to show how
different colour palettes can help explain the project and give a better
sense of where you are on the website.
I've done a lot of research on the project, but some things may be
wrong. So your feedback on that would be greatly appreciated. Even after
spending many months with the project, I still don't fully grasp
everything (which shows part of the problem).
1. Naming
I've split up the project into three main subprojects: "AeroGear Core",
"AeroGear Push", and "AeroGear Security". These three are the main
focus
and use different icons and colour codings throughout the website to
guide people. Each subproject has "client" and "server" components.
Server pieces being appended by "Server Component" and may be standalone
or an addin to something. Client (API) pieces follow "Project.Namespace"
format. This way, there's never any confusion about what we're talking
about in the documentation and marketing materials.
2. Documentation
Splitting up documentation. "documentation" can be a broad term. I
suggest splitting it up in three parts to easily find what you're
looking for: "Setting up" (downloading and boatstrapping a dev
environment), "Examples" (how to use the API in your environment to get
started), "API Documentation" (speaks for itself), and "Tutorials"
(setting up more complex environments and API usage). This covers most
of the documentation that is currently on aerogear.org and will make it
a lot easier to browse.
3. Coding languages
Where the API is unified across all platforms (hopefully most of it), we
can generalise example docs, and show a switcher for code blocks that
shows how to do a certain thing in a particular language using the
AeroGear API.
4. 1:1 mappings
I'd like to see the iOS, Android and Javscript APIs be self-contained
things that you can just drop in and use, with 1:1 mappings (what you
get on Android for a (sub)project, is what you get on iOS). There could
be technical reasons why these things are split up the way they are now,
let me know if so. I could be totally wrong on this too.
Missing pieces:
- Where do we fit in Cordova?
- AeroGear Auth, Controller?
These are things I'm not sure yet how they would fit in the proposed scheme.
I think this is a step in the right direction, and I really hope it is
helpful. Let's iterate on this. Let me know what you think and how we
can improve. Looking forward to hear your opinions on this.
Thanks,
Hylke
9:11 a.m.
Hello Hylke
I really like the idea of using colour to gather together features.
Just a very general question before delving into detailled sections: is this new proposal
supposed to integrate with actual site design? just redesigning the documentation section
or is it a complete rewamp of the site? Because i'm not sure the colours match the
existing ones on the site.
More questions to come later :)
++
Corinne
On Nov 4, 2013, at 4:24 PM, Hylke Bons <hbons(a)redhat.com> wrote:
Hey everyone,
So Jay asked me to look at how the website content is structured and how
to improve it. Since we have so much content, it gets confusing very
quickly.
https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
Here's a mockup of a possible solution. I'm better at explaining things
in pictures than in words, so please have a look. I'll explain things in
more detail below.
I've tried to keep every subproject use case based, and explain the use
case before features. See this as a bigger picture, and don't focus on
the graphic design too much, it's there to help explain the structure of
the project, and is not necessarilly a final graphical design in any way
(though if you like it we can make it work!), but I wanted to show how
different colour palettes can help explain the project and give a better
sense of where you are on the website.
I've done a lot of research on the project, but some things may be
wrong. So your feedback on that would be greatly appreciated. Even after
spending many months with the project, I still don't fully grasp
everything (which shows part of the problem).
1. Naming
I've split up the project into three main subprojects: "AeroGear Core",
"AeroGear Push", and "AeroGear Security". These three are the main
focus
and use different icons and colour codings throughout the website to
guide people. Each subproject has "client" and "server" components.
Server pieces being appended by "Server Component" and may be standalone
or an addin to something. Client (API) pieces follow "Project.Namespace"
format. This way, there's never any confusion about what we're talking
about in the documentation and marketing materials.
2. Documentation
Splitting up documentation. "documentation" can be a broad term. I
suggest splitting it up in three parts to easily find what you're
looking for: "Setting up" (downloading and boatstrapping a dev
environment), "Examples" (how to use the API in your environment to get
started), "API Documentation" (speaks for itself), and "Tutorials"
(setting up more complex environments and API usage). This covers most
of the documentation that is currently on aerogear.org and will make it
a lot easier to browse.
3. Coding languages
Where the API is unified across all platforms (hopefully most of it), we
can generalise example docs, and show a switcher for code blocks that
shows how to do a certain thing in a particular language using the
AeroGear API.
4. 1:1 mappings
I'd like to see the iOS, Android and Javscript APIs be self-contained
things that you can just drop in and use, with 1:1 mappings (what you
get on Android for a (sub)project, is what you get on iOS). There could
be technical reasons why these things are split up the way they are now,
let me know if so. I could be totally wrong on this too.
Missing pieces:
- Where do we fit in Cordova?
- AeroGear Auth, Controller?
These are things I'm not sure yet how they would fit in the proposed scheme.
I think this is a step in the right direction, and I really hope it is
helpful. Let's iterate on this. Let me know what you think and how we
can improve. Looking forward to hear your opinions on this.
Thanks,
Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:52 a.m.
Hey Corinne,
It's an example of how we can use colours. We can use the current site
styling as well, it depends on which one is liked most. The previous
redesign was pretty generic and was mainly to clean things up a bit. If
the team like the kind of darker styling we can do that as well. I was
just expermenting a bit. :)
Hylke
On 05/11/2013 08:11, Corinne Krych wrote:
Hello Hylke
I really like the idea of using colour to gather together features.
Just a very general question before delving into detailled sections: is this new proposal
supposed to integrate with actual site design? just redesigning the documentation section
or is it a complete rewamp of the site? Because i'm not sure the colours match the
existing ones on the site.
More questions to come later :)
++
Corinne
On Nov 4, 2013, at 4:24 PM, Hylke Bons <hbons(a)redhat.com> wrote:
> Hey everyone,
>
> So Jay asked me to look at how the website content is structured and how
> to improve it. Since we have so much content, it gets confusing very
> quickly.
>
> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>
> Here's a mockup of a possible solution. I'm better at explaining things
> in pictures than in words, so please have a look. I'll explain things in
> more detail below.
>
> I've tried to keep every subproject use case based, and explain the use
> case before features. See this as a bigger picture, and don't focus on
> the graphic design too much, it's there to help explain the structure of
> the project, and is not necessarilly a final graphical design in any way
> (though if you like it we can make it work!), but I wanted to show how
> different colour palettes can help explain the project and give a better
> sense of where you are on the website.
>
> I've done a lot of research on the project, but some things may be
> wrong. So your feedback on that would be greatly appreciated. Even after
> spending many months with the project, I still don't fully grasp
> everything (which shows part of the problem).
>
> 1. Naming
> I've split up the project into three main subprojects: "AeroGear
Core",
> "AeroGear Push", and "AeroGear Security". These three are the
main focus
> and use different icons and colour codings throughout the website to
> guide people. Each subproject has "client" and "server"
components.
> Server pieces being appended by "Server Component" and may be standalone
> or an addin to something. Client (API) pieces follow "Project.Namespace"
> format. This way, there's never any confusion about what we're talking
> about in the documentation and marketing materials.
>
> 2. Documentation
> Splitting up documentation. "documentation" can be a broad term. I
> suggest splitting it up in three parts to easily find what you're
> looking for: "Setting up" (downloading and boatstrapping a dev
> environment), "Examples" (how to use the API in your environment to get
> started), "API Documentation" (speaks for itself), and
"Tutorials"
> (setting up more complex environments and API usage). This covers most
> of the documentation that is currently on aerogear.org and will make it
> a lot easier to browse.
>
> 3. Coding languages
> Where the API is unified across all platforms (hopefully most of it), we
> can generalise example docs, and show a switcher for code blocks that
> shows how to do a certain thing in a particular language using the
> AeroGear API.
>
> 4. 1:1 mappings
> I'd like to see the iOS, Android and Javscript APIs be self-contained
> things that you can just drop in and use, with 1:1 mappings (what you
> get on Android for a (sub)project, is what you get on iOS). There could
> be technical reasons why these things are split up the way they are now,
> let me know if so. I could be totally wrong on this too.
>
> Missing pieces:
> - Where do we fit in Cordova?
> - AeroGear Auth, Controller?
>
> These are things I'm not sure yet how they would fit in the proposed scheme.
>
> I think this is a step in the right direction, and I really hope it is
> helpful. Let's iterate on this. Let me know what you think and how we
> can improve. Looking forward to hear your opinions on this.
>
> Thanks,
>
> Hylke
> _______________________________________________
> 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
11:25 a.m.
The advantage with the dark color design is that it will highlight UX colour code. With
light grey color of actual site not sure bright color will fit.
But if we go that route, it would be nice to have a main page mockup. Note you also
changed (slightly) footer design.
On the other hand if we stick with existing grey shades, which colour would you use?
++
Corinne
On Nov 5, 2013, at 10:52 AM, Hylke Bons <hbons(a)redhat.com> wrote:
Hey Corinne,
It's an example of how we can use colours. We can use the current site
styling as well, it depends on which one is liked most. The previous
redesign was pretty generic and was mainly to clean things up a bit. If
the team like the kind of darker styling we can do that as well. I was
just expermenting a bit. :)
Hylke
On 05/11/2013 08:11, Corinne Krych wrote:
> Hello Hylke
>
> I really like the idea of using colour to gather together features.
> Just a very general question before delving into detailled sections: is this new
proposal supposed to integrate with actual site design? just redesigning the documentation
section or is it a complete rewamp of the site? Because i'm not sure the colours match
the existing ones on the site.
>
> More questions to come later :)
>
> ++
> Corinne
> On Nov 4, 2013, at 4:24 PM, Hylke Bons <hbons(a)redhat.com> wrote:
>
>> Hey everyone,
>>
>> So Jay asked me to look at how the website content is structured and how
>> to improve it. Since we have so much content, it gets confusing very
>> quickly.
>>
>> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>>
>> Here's a mockup of a possible solution. I'm better at explaining things
>> in pictures than in words, so please have a look. I'll explain things in
>> more detail below.
>>
>> I've tried to keep every subproject use case based, and explain the use
>> case before features. See this as a bigger picture, and don't focus on
>> the graphic design too much, it's there to help explain the structure of
>> the project, and is not necessarilly a final graphical design in any way
>> (though if you like it we can make it work!), but I wanted to show how
>> different colour palettes can help explain the project and give a better
>> sense of where you are on the website.
>>
>> I've done a lot of research on the project, but some things may be
>> wrong. So your feedback on that would be greatly appreciated. Even after
>> spending many months with the project, I still don't fully grasp
>> everything (which shows part of the problem).
>>
>> 1. Naming
>> I've split up the project into three main subprojects: "AeroGear
Core",
>> "AeroGear Push", and "AeroGear Security". These three are the
main focus
>> and use different icons and colour codings throughout the website to
>> guide people. Each subproject has "client" and "server"
components.
>> Server pieces being appended by "Server Component" and may be
standalone
>> or an addin to something. Client (API) pieces follow
"Project.Namespace"
>> format. This way, there's never any confusion about what we're talking
>> about in the documentation and marketing materials.
>>
>> 2. Documentation
>> Splitting up documentation. "documentation" can be a broad term. I
>> suggest splitting it up in three parts to easily find what you're
>> looking for: "Setting up" (downloading and boatstrapping a dev
>> environment), "Examples" (how to use the API in your environment to
get
>> started), "API Documentation" (speaks for itself), and
"Tutorials"
>> (setting up more complex environments and API usage). This covers most
>> of the documentation that is currently on aerogear.org and will make it
>> a lot easier to browse.
>>
>> 3. Coding languages
>> Where the API is unified across all platforms (hopefully most of it), we
>> can generalise example docs, and show a switcher for code blocks that
>> shows how to do a certain thing in a particular language using the
>> AeroGear API.
>>
>> 4. 1:1 mappings
>> I'd like to see the iOS, Android and Javscript APIs be self-contained
>> things that you can just drop in and use, with 1:1 mappings (what you
>> get on Android for a (sub)project, is what you get on iOS). There could
>> be technical reasons why these things are split up the way they are now,
>> let me know if so. I could be totally wrong on this too.
>>
>> Missing pieces:
>> - Where do we fit in Cordova?
>> - AeroGear Auth, Controller?
>>
>> These are things I'm not sure yet how they would fit in the proposed scheme.
>>
>> I think this is a step in the right direction, and I really hope it is
>> helpful. Let's iterate on this. Let me know what you think and how we
>> can improve. Looking forward to hear your opinions on this.
>>
>> Thanks,
>>
>> Hylke
>> _______________________________________________
>> 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
11:37 a.m.
On 05/11/2013 10:25, Corinne Krych wrote:
The advantage with the dark color design is that it will highlight UX
colour code. With light grey color of actual site not sure bright color will fit.
Yep, you are completely right. This is why I choose the dark background,
so the colours stand out better.
But if we go that route, it would be nice to have a main page mockup.
Note you also changed (slightly) footer design.
The page on the left would be the home page, or do you mean something
else by "main" page? :)
On the other hand if we stick with existing grey shades, which colour would you use?
I would use a slightly darker grey instead of the black for the
subproject descriptions, so that the highlights will still stand out.
Hylke
++
Corinne
On Nov 5, 2013, at 10:52 AM, Hylke Bons <hbons(a)redhat.com> wrote:
> Hey Corinne,
>
> It's an example of how we can use colours. We can use the current site
> styling as well, it depends on which one is liked most. The previous
> redesign was pretty generic and was mainly to clean things up a bit. If
> the team like the kind of darker styling we can do that as well. I was
> just expermenting a bit. :)
>
> Hylke
>
>
>
> On 05/11/2013 08:11, Corinne Krych wrote:
>> Hello Hylke
>>
>> I really like the idea of using colour to gather together features.
>> Just a very general question before delving into detailled sections: is this new
proposal supposed to integrate with actual site design? just redesigning the documentation
section or is it a complete rewamp of the site? Because i'm not sure the colours match
the existing ones on the site.
>>
>> More questions to come later :)
>>
>> ++
>> Corinne
>> On Nov 4, 2013, at 4:24 PM, Hylke Bons <hbons(a)redhat.com> wrote:
>>
>>> Hey everyone,
>>>
>>> So Jay asked me to look at how the website content is structured and how
>>> to improve it. Since we have so much content, it gets confusing very
>>> quickly.
>>>
>>> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>>>
>>> Here's a mockup of a possible solution. I'm better at explaining
things
>>> in pictures than in words, so please have a look. I'll explain things in
>>> more detail below.
>>>
>>> I've tried to keep every subproject use case based, and explain the use
>>> case before features. See this as a bigger picture, and don't focus on
>>> the graphic design too much, it's there to help explain the structure of
>>> the project, and is not necessarilly a final graphical design in any way
>>> (though if you like it we can make it work!), but I wanted to show how
>>> different colour palettes can help explain the project and give a better
>>> sense of where you are on the website.
>>>
>>> I've done a lot of research on the project, but some things may be
>>> wrong. So your feedback on that would be greatly appreciated. Even after
>>> spending many months with the project, I still don't fully grasp
>>> everything (which shows part of the problem).
>>>
>>> 1. Naming
>>> I've split up the project into three main subprojects: "AeroGear
Core",
>>> "AeroGear Push", and "AeroGear Security". These three are
the main focus
>>> and use different icons and colour codings throughout the website to
>>> guide people. Each subproject has "client" and "server"
components.
>>> Server pieces being appended by "Server Component" and may be
standalone
>>> or an addin to something. Client (API) pieces follow
"Project.Namespace"
>>> format. This way, there's never any confusion about what we're
talking
>>> about in the documentation and marketing materials.
>>>
>>> 2. Documentation
>>> Splitting up documentation. "documentation" can be a broad term. I
>>> suggest splitting it up in three parts to easily find what you're
>>> looking for: "Setting up" (downloading and boatstrapping a dev
>>> environment), "Examples" (how to use the API in your environment to
get
>>> started), "API Documentation" (speaks for itself), and
"Tutorials"
>>> (setting up more complex environments and API usage). This covers most
>>> of the documentation that is currently on aerogear.org and will make it
>>> a lot easier to browse.
>>>
>>> 3. Coding languages
>>> Where the API is unified across all platforms (hopefully most of it), we
>>> can generalise example docs, and show a switcher for code blocks that
>>> shows how to do a certain thing in a particular language using the
>>> AeroGear API.
>>>
>>> 4. 1:1 mappings
>>> I'd like to see the iOS, Android and Javscript APIs be self-contained
>>> things that you can just drop in and use, with 1:1 mappings (what you
>>> get on Android for a (sub)project, is what you get on iOS). There could
>>> be technical reasons why these things are split up the way they are now,
>>> let me know if so. I could be totally wrong on this too.
>>>
>>> Missing pieces:
>>> - Where do we fit in Cordova?
>>> - AeroGear Auth, Controller?
>>>
>>> These are things I'm not sure yet how they would fit in the proposed
scheme.
>>>
>>> I think this is a step in the right direction, and I really hope it is
>>> helpful. Let's iterate on this. Let me know what you think and how we
>>> can improve. Looking forward to hear your opinions on this.
>>>
>>> Thanks,
>>>
>>> Hylke
>>> _______________________________________________
>>> 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
11:56 a.m.
On Nov 5, 2013, at 11:37 AM, Hylke Bons <hbons(a)redhat.com> wrote:
On 05/11/2013 10:25, Corinne Krych wrote:
> The advantage with the dark color design is that it will highlight UX colour code.
With light grey color of actual site not sure bright color will fit.
Yep, you are completely right. This is why I choose the dark background,
so the colours stand out better.
> But if we go that route, it would be nice to have a main page mockup. Note you also
changed (slightly) footer design.
The page on the left would be the home page, or do you mean something
else by "main" page? :)
Ooops sorry didn't pay enough attention. I missed the home page label.
With the new design, the idea is to stress the features and client/server aspect of the
AeroGear, but one thing I liked about the previous design is: on the main page there is
the 4 icons: iOS, web, android, cordova which show the supported client platforms. I'm
missing those icons. how can we add that information?
>
> On the other hand if we stick with existing grey shades, which colour would you use?
I would use a slightly darker grey instead of the black for the
subproject descriptions, so that the highlights will still stand out.
Hylke
>
> ++
> Corinne
> On Nov 5, 2013, at 10:52 AM, Hylke Bons <hbons(a)redhat.com> wrote:
>
>> Hey Corinne,
>>
>> It's an example of how we can use colours. We can use the current site
>> styling as well, it depends on which one is liked most. The previous
>> redesign was pretty generic and was mainly to clean things up a bit. If
>> the team like the kind of darker styling we can do that as well. I was
>> just expermenting a bit. :)
>>
>> Hylke
>>
>>
>>
>> On 05/11/2013 08:11, Corinne Krych wrote:
>>> Hello Hylke
>>>
>>> I really like the idea of using colour to gather together features.
>>> Just a very general question before delving into detailled sections: is this
new proposal supposed to integrate with actual site design? just redesigning the
documentation section or is it a complete rewamp of the site? Because i'm not sure the
colours match the existing ones on the site.
>>>
>>> More questions to come later :)
>>>
>>> ++
>>> Corinne
>>> On Nov 4, 2013, at 4:24 PM, Hylke Bons <hbons(a)redhat.com> wrote:
>>>
>>>> Hey everyone,
>>>>
>>>> So Jay asked me to look at how the website content is structured and how
>>>> to improve it. Since we have so much content, it gets confusing very
>>>> quickly.
>>>>
>>>> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>>>>
>>>> Here's a mockup of a possible solution. I'm better at explaining
things
>>>> in pictures than in words, so please have a look. I'll explain things
in
>>>> more detail below.
>>>>
>>>> I've tried to keep every subproject use case based, and explain the
use
>>>> case before features. See this as a bigger picture, and don't focus
on
>>>> the graphic design too much, it's there to help explain the structure
of
>>>> the project, and is not necessarilly a final graphical design in any way
>>>> (though if you like it we can make it work!), but I wanted to show how
>>>> different colour palettes can help explain the project and give a better
>>>> sense of where you are on the website.
>>>>
>>>> I've done a lot of research on the project, but some things may be
>>>> wrong. So your feedback on that would be greatly appreciated. Even after
>>>> spending many months with the project, I still don't fully grasp
>>>> everything (which shows part of the problem).
>>>>
>>>> 1. Naming
>>>> I've split up the project into three main subprojects: "AeroGear
Core",
>>>> "AeroGear Push", and "AeroGear Security". These three
are the main focus
>>>> and use different icons and colour codings throughout the website to
>>>> guide people. Each subproject has "client" and
"server" components.
>>>> Server pieces being appended by "Server Component" and may be
standalone
>>>> or an addin to something. Client (API) pieces follow
"Project.Namespace"
>>>> format. This way, there's never any confusion about what we're
talking
>>>> about in the documentation and marketing materials.
>>>>
>>>> 2. Documentation
>>>> Splitting up documentation. "documentation" can be a broad
term. I
>>>> suggest splitting it up in three parts to easily find what you're
>>>> looking for: "Setting up" (downloading and boatstrapping a dev
>>>> environment), "Examples" (how to use the API in your
environment to get
>>>> started), "API Documentation" (speaks for itself), and
"Tutorials"
>>>> (setting up more complex environments and API usage). This covers most
>>>> of the documentation that is currently on aerogear.org and will make it
>>>> a lot easier to browse.
>>>>
>>>> 3. Coding languages
>>>> Where the API is unified across all platforms (hopefully most of it), we
>>>> can generalise example docs, and show a switcher for code blocks that
>>>> shows how to do a certain thing in a particular language using the
>>>> AeroGear API.
>>>>
>>>> 4. 1:1 mappings
>>>> I'd like to see the iOS, Android and Javscript APIs be
self-contained
>>>> things that you can just drop in and use, with 1:1 mappings (what you
>>>> get on Android for a (sub)project, is what you get on iOS). There could
>>>> be technical reasons why these things are split up the way they are now,
>>>> let me know if so. I could be totally wrong on this too.
>>>>
>>>> Missing pieces:
>>>> - Where do we fit in Cordova?
>>>> - AeroGear Auth, Controller?
>>>>
>>>> These are things I'm not sure yet how they would fit in the proposed
scheme.
>>>>
>>>> I think this is a step in the right direction, and I really hope it is
>>>> helpful. Let's iterate on this. Let me know what you think and how
we
>>>> can improve. Looking forward to hear your opinions on this.
>>>>
>>>> Thanks,
>>>>
>>>> Hylke
>>>> _______________________________________________
>>>> 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
12:34 p.m.
On 05/11/2013 10:56, Corinne Krych wrote:
> The page on the left would be the home page, or do you mean something
> else by "main" page? :)
Ooops sorry didn't pay enough attention. I missed the home page label.
With the new design, the idea is to stress the features and client/server aspect of the
AeroGear, but one thing I liked about the previous design is: on the main page there is
the 4 icons: iOS, web, android, cordova which show the supported client platforms. I'm
missing those icons. how can we add that information?
So the reason I removed those was because the emphasis was on on
platforms, instead of use cases.
When I visit this page I'd like to be shown reasons why I should use
AeroGear and in what ways it can help me. The platform icons alone
didn't do that for me. Now, of course, being multiplatform is a good
selling point too but only after you've figured what you want to do, it
isn't the main one.
I do agree though that we can emphasise a little bit more on being
crossplatform other than just having some references in the text (as
people don't read :). I'll see if I can bring the icons back in a subtle
way at the top of the page without being the main emphasis.
Hylke
5:46 p.m.
On 11/04/2013 10:24 AM, Hylke Bons wrote:
Hey everyone,
So Jay asked me to look at how the website content is structured and how
to improve it. Since we have so much content, it gets confusing very
quickly.
https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
Here's a mockup of a possible solution. I'm better at explaining things
in pictures than in words, so please have a look. I'll explain things in
more detail below.
I've tried to keep every subproject use case based, and explain the use
case before features. See this as a bigger picture, and don't focus on
the graphic design too much, it's there to help explain the structure of
the project, and is not necessarilly a final graphical design in any way
(though if you like it we can make it work!), but I wanted to show how
different colour palettes can help explain the project and give a better
sense of where you are on the website.
I've done a lot of research on the project, but some things may be
wrong. So your feedback on that would be greatly appreciated. Even after
spending many months with the project, I still don't fully grasp
everything (which shows part of the problem).
1. Naming
I've split up the project into three main subprojects: "AeroGear Core",
"AeroGear Push", and "AeroGear Security". These three are the main
focus
and use different icons and colour codings throughout the website to
guide people. Each subproject has "client" and "server" components.
Server pieces being appended by "Server Component" and may be standalone
or an addin to something. Client (API) pieces follow "Project.Namespace"
format. This way, there's never any confusion about what we're talking
about in the documentation and marketing materials.
2. Documentation
Splitting up documentation. "documentation" can be a broad term. I
suggest splitting it up in three parts to easily find what you're
looking for: "Setting up" (downloading and boatstrapping a dev
environment), "Examples" (how to use the API in your environment to get
started), "API Documentation" (speaks for itself), and "Tutorials"
(setting up more complex environments and API usage). This covers most
of the documentation that is currently on aerogear.org and will make it
a lot easier to browse.
3. Coding languages
Where the API is unified across all platforms (hopefully most of it), we
can generalise example docs, and show a switcher for code blocks that
shows how to do a certain thing in a particular language using the
AeroGear API.
4. 1:1 mappings
I'd like to see the iOS, Android and Javscript APIs be self-contained
things that you can just drop in and use, with 1:1 mappings (what you
get on Android for a (sub)project, is what you get on iOS). There could
be technical reasons why these things are split up the way they are now,
let me know if so. I could be totally wrong on this too.
Missing pieces:
- Where do we fit in Cordova?
- AeroGear Auth, Controller?
AeroGear Controller is deprecated so that one is easy
:)
These are things I'm not sure yet how they would fit in the proposed scheme.
I think this is a step in the right direction, and I really hope it is
helpful. Let's iterate on this. Let me know what you think and how we
can improve. Looking forward to hear your opinions on this.
Thanks,
Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:31 a.m.
Hylke, really like the colour idea reminds me of supermarket products:
for instance salt Crisps being packed in a red packs by all brands.
On 5 Nov,2013, at 17:46 , Summers Pittman <supittma(a)redhat.com> wrote:
On 11/04/2013 10:24 AM, Hylke Bons wrote:
>
> 3. Coding languages
> Where the API is unified across all platforms (hopefully most of it), we
> can generalise example docs, and show a switcher for code blocks that
> shows how to do a certain thing in a particular language using the
> AeroGear API.
>
I would suggest that Cordova is in this switcher as well. Because you can see it as an
api
that we offer that does the same thing but on another platform.
> 4. 1:1 mappings
> I'd like to see the iOS, Android and Javscript APIs be self-contained
> things that you can just drop in and use, with 1:1 mappings (what you
> get on Android for a (sub)project, is what you get on iOS). There could
> be technical reasons why these things are split up the way they are now,
> let me know if so. I could be totally wrong on this too.
>
11:35 a.m.
On 06/11/2013 10:31, Erik Jan de Wit wrote:
Hylke, really like the colour idea reminds me of supermarket
products:
for instance salt Crisps being packed in a red packs by all brands.
Maybe we can do
something funny with pack icons. :)
On 5 Nov,2013, at 17:46 , Summers Pittman <supittma(a)redhat.com>
wrote:
> On 11/04/2013 10:24 AM, Hylke Bons wrote:
>> 3. Coding languages
>> Where the API is unified across all platforms (hopefully most of it), we
>> can generalise example docs, and show a switcher for code blocks that
>> shows how to do a certain thing in a particular language using the
>> AeroGear API.
>>
I would suggest that Cordova is in this switcher as well. Because you can see it as an
api
that we offer that does the same thing but on another platform.
That could do the trick. I'll add it as an icon and give it a mention as
well as per Corinne's suggestion.
Hylke
>> 4. 1:1 mappings
>> I'd like to see the iOS, Android and Javscript APIs be self-contained
>> things that you can just drop in and use, with 1:1 mappings (what you
>> get on Android for a (sub)project, is what you get on iOS). There could
>> be technical reasons why these things are split up the way they are now,
>> let me know if so. I could be totally wrong on this too.
>>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:42 a.m.
On Nov 6, 2013, at 11:35 AM, Hylke Bons <hbons(a)redhat.com> wrote:
On 06/11/2013 10:31, Erik Jan de Wit wrote:
> Hylke, really like the colour idea reminds me of supermarket products:
> for instance salt Crisps being packed in a red packs by all brands.
Maybe we can do something funny with pack icons. :)
> On 5 Nov,2013, at 17:46 , Summers Pittman <supittma(a)redhat.com> wrote:
>
>> On 11/04/2013 10:24 AM, Hylke Bons wrote:
>>> 3. Coding languages
>>> Where the API is unified across all platforms (hopefully most of it), we
>>> can generalise example docs, and show a switcher for code blocks that
>>> shows how to do a certain thing in a particular language using the
>>> AeroGear API.
>>>
> I would suggest that Cordova is in this switcher as well. Because you can see it as
an api
> that we offer that does the same thing but on another platform.
That could do the trick. I'll add it as an icon and give it a mention as
well as per Corinne's suggestion.
Hylke
Yep rather than 'coding languages' it's more 'client platforms' I
guess and cordova has its place here IMO.
Corinne
>
>>> 4. 1:1 mappings
>>> I'd like to see the iOS, Android and Javscript APIs be self-contained
>>> things that you can just drop in and use, with 1:1 mappings (what you
>>> get on Android for a (sub)project, is what you get on iOS). There could
>>> be technical reasons why these things are split up the way they are now,
>>> let me know if so. I could be totally wrong on this too.
>>>
>
> _______________________________________________
> 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
4:28 p.m.
On 05/11/2013 16:46, Summers Pittman wrote:
On 11/04/2013 10:24 AM, Hylke Bons wrote:
Missing pieces:
- Where do we fit in Cordova?
- AeroGear Auth, Controller?
AeroGear Controller is deprecated so that one is easy :)
Problem solved. :)
> These are things I'm not sure yet how they would fit in the
proposed scheme.
>
> I think this is a step in the right direction, and I really hope it is
> helpful. Let's iterate on this. Let me know what you think and how we
> can improve. Looking forward to hear your opinions on this.
>
> Thanks,
>
> Hylke
> _______________________________________________
> 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
3:41 p.m.
Hi All,
I'm just going to reply to the original email. There has been some good discussions
in the thread though and for the most part I agree with other emails.
Most of my comments will be inline, but in general:
I like the idea of using colors and lots of your ideas around APIs, doc areas, etc... My
main concern is about drastically changing the current site as we've had several
redesigns ( a couple before you came, and then you last one, and this proposed on).
I'd like to make sure we explore integrating some of your ideas, but keeping core
aerogear.org site mostly intact. So lets work on color scheme's, content updates,
API/coding presentations, etc... within the context of the current site if at all
possible.
On Nov 4, 2013, at 10:24 AM, Hylke Bons <hbons(a)redhat.com> wrote:
Hey everyone,
So Jay asked me to look at how the website content is structured and how
to improve it. Since we have so much content, it gets confusing very
quickly.
https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
Here's a mockup of a possible solution. I'm better at explaining things
in pictures than in words, so please have a look. I'll explain things in
more detail below.
I've tried to keep every subproject use case based, and explain the use
case before features. See this as a bigger picture, and don't focus on
the graphic design too much, it's there to help explain the structure of
the project, and is not necessarilly a final graphical design in any way
(though if you like it we can make it work!), but I wanted to show how
different colour palettes can help explain the project and give a better
sense of where you are on the website.
As I mention I really do like the color coding, and especially being use-case driven. I
also agree with corrine that on the home page I'd like to make sure we keep the
platform icons (I like those a lot as well), but perhaps work in use-cases (below, above,
etc...), or use case drive in the sub-pages?
I've done a lot of research on the project, but some things may be
wrong. So your feedback on that would be greatly appreciated. Even after
spending many months with the project, I still don't fully grasp
everything (which shows part of the problem).
1. Naming
I've split up the project into three main subprojects: "AeroGear Core",
"AeroGear Push", and "AeroGear Security". These three are the main
focus
and use different icons and colour codings throughout the website to
guide people. Each subproject has "client" and "server" components.
Server pieces being appended by "Server Component" and may be standalone
or an addin to something. Client (API) pieces follow "Project.Namespace"
format. This way, there's never any confusion about what we're talking
about in the documentation and marketing materials.
+1 on color scheme - and agree with server/client aspects of each. We really have 2
matrixes here; platform (iOS, Android, etc..) & feature (use-case) perhaps there is a
paradigm or structure to showing both somehow?
2. Documentation
Splitting up documentation. "documentation" can be a broad term. I
suggest splitting it up in three parts to easily find what you're
looking for: "Setting up" (downloading and boatstrapping a dev
environment), "Examples" (how to use the API in your environment to get
started), "API Documentation" (speaks for itself), and "Tutorials"
(setting up more complex environments and API usage). This covers most
of the documentation that is currently on aerogear.org and will make it
a lot easier to browse.
+100 our doc sections needs a good cleaning, organizing, and a better way to navigate and
view.
3. Coding languages
Where the API is unified across all platforms (hopefully most of it), we
can generalise example docs, and show a switcher for code blocks that
shows how to do a certain thing in a particular language using the
AeroGear API.
+1 I like the idea of common docs, with some context switch ability to shift platform.
This will not always be possible but I think it could be on many of our features. It
might also help point out issues or mis-matches between libraries.
4. 1:1 mappings
I'd like to see the iOS, Android and Javscript APIs be self-contained
things that you can just drop in and use, with 1:1 mappings (what you
get on Android for a (sub)project, is what you get on iOS). There could
be technical reasons why these things are split up the way they are now,
let me know if so. I could be totally wrong on this too.
As above there is not always a 1:1 mapping.
Missing pieces:
- Where do we fit in Cordova?
As Erik said - Cordova is a another core platform and should be featured.
- AeroGear Auth, Controller?
These are things I'm not sure yet how they would fit in the proposed scheme.
I think this is a step in the right direction, and I really hope it is
helpful. Let's iterate on this. Let me know what you think and how we
can improve. Looking forward to hear your opinions on this.
Good stuff Hylke, and sorry for the delay getting back to you!
Thanks,
Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:20 a.m.
Thanks Jay for giving us feedback.
+1 on building on existing website
To fit color code from Hylke, we need to adjust the light grey, pastel colour we used for
more contrasted colours.
Thinking ahead about this colour revamp, I've delved into CSS preprocessor. I think
aerogear.org would benefit using one:
- with help of variable, changing colour, size etc.. is made easy. Help defined color
palette.
- with @media and mixin, responsiveness is made easier to maintain
- and much more.. the good thing is you can apply/create mixin as you go and refactor in
iteration
I've done a first trial with SASS on that branch [1].
Similar work a bit less in details though with Sylus [2].
Choosing which preprocessor to use is like choosing which color fit you well.
I personnally go for Sass. I like its maturity, strong community. Latest addition Scut [3]
has interesting set of mixins. I was impressed by sass reverse engineering command that
let you move your CSS to sass file. it works like a charm.
My second choice would be Stylus. As we're using some Topcoat's component (menu).
Last option is Less.
Here a presentation I'll give next Thursday on preprocessor topic [4].
Let's move forward, if Hylke can pick colour on we could start with revamp colours +
CSS precporcessot
Then add some refactoring on main page content. I'd like to break it down into several
JIRAs to avoid too big PRs syndrome.
wdyt?
++
Corinne
[1] https://github.com/corinnekrych/aerogear.org/tree/sass#building-css
[2] https://github.com/corinnekrych/aerogear.org/tree/stylus
[3] http://css-tricks.com/introducing-scut-new-sass-utility-library/
[4] http://corinnekrych.github.io/preproCeSSor/
On Nov 25, 2013, at 3:41 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
Hi All,
I'm just going to reply to the original email. There has been some good discussions
in the thread though and for the most part I agree with other emails.
Most of my comments will be inline, but in general:
I like the idea of using colors and lots of your ideas around APIs, doc areas, etc... My
main concern is about drastically changing the current site as we've had several
redesigns ( a couple before you came, and then you last one, and this proposed on).
I'd like to make sure we explore integrating some of your ideas, but keeping core
aerogear.org site mostly intact. So lets work on color scheme's, content updates,
API/coding presentations, etc... within the context of the current site if at all
possible.
On Nov 4, 2013, at 10:24 AM, Hylke Bons <hbons(a)redhat.com> wrote:
> Hey everyone,
>
> So Jay asked me to look at how the website content is structured and how
> to improve it. Since we have so much content, it gets confusing very
> quickly.
>
> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>
> Here's a mockup of a possible solution. I'm better at explaining things
> in pictures than in words, so please have a look. I'll explain things in
> more detail below.
>
> I've tried to keep every subproject use case based, and explain the use
> case before features. See this as a bigger picture, and don't focus on
> the graphic design too much, it's there to help explain the structure of
> the project, and is not necessarilly a final graphical design in any way
> (though if you like it we can make it work!), but I wanted to show how
> different colour palettes can help explain the project and give a better
> sense of where you are on the website.
As I mention I really do like the color coding, and especially being use-case driven. I
also agree with corrine that on the home page I'd like to make sure we keep the
platform icons (I like those a lot as well), but perhaps work in use-cases (below, above,
etc...), or use case drive in the sub-pages?
>
> I've done a lot of research on the project, but some things may be
> wrong. So your feedback on that would be greatly appreciated. Even after
> spending many months with the project, I still don't fully grasp
> everything (which shows part of the problem).
>
> 1. Naming
> I've split up the project into three main subprojects: "AeroGear Core",
> "AeroGear Push", and "AeroGear Security". These three are the
main focus
> and use different icons and colour codings throughout the website to
> guide people. Each subproject has "client" and "server"
components.
> Server pieces being appended by "Server Component" and may be standalone
> or an addin to something. Client (API) pieces follow "Project.Namespace"
> format. This way, there's never any confusion about what we're talking
> about in the documentation and marketing materials.
>
+1 on color scheme - and agree with server/client aspects of each. We really have 2
matrixes here; platform (iOS, Android, etc..) & feature (use-case) perhaps there is a
paradigm or structure to showing both somehow?
> 2. Documentation
> Splitting up documentation. "documentation" can be a broad term. I
> suggest splitting it up in three parts to easily find what you're
> looking for: "Setting up" (downloading and boatstrapping a dev
> environment), "Examples" (how to use the API in your environment to get
> started), "API Documentation" (speaks for itself), and
"Tutorials"
> (setting up more complex environments and API usage). This covers most
> of the documentation that is currently on aerogear.org and will make it
> a lot easier to browse.
+100 our doc sections needs a good cleaning, organizing, and a better way to navigate and
view.
>
> 3. Coding languages
> Where the API is unified across all platforms (hopefully most of it), we
> can generalise example docs, and show a switcher for code blocks that
> shows how to do a certain thing in a particular language using the
> AeroGear API.
+1 I like the idea of common docs, with some context switch ability to shift platform.
This will not always be possible but I think it could be on many of our features. It
might also help point out issues or mis-matches between libraries.
>
> 4. 1:1 mappings
> I'd like to see the iOS, Android and Javscript APIs be self-contained
> things that you can just drop in and use, with 1:1 mappings (what you
> get on Android for a (sub)project, is what you get on iOS). There could
> be technical reasons why these things are split up the way they are now,
> let me know if so. I could be totally wrong on this too.
As above there is not always a 1:1 mapping.
>
> Missing pieces:
> - Where do we fit in Cordova?
As Erik said - Cordova is a another core platform and should be featured.
> - AeroGear Auth, Controller?
>
> These are things I'm not sure yet how they would fit in the proposed scheme.
>
> I think this is a step in the right direction, and I really hope it is
> helpful. Let's iterate on this. Let me know what you think and how we
> can improve. Looking forward to hear your opinions on this.
Good stuff Hylke, and sorry for the delay getting back to you!
>
> Thanks,
>
> Hylke
> _______________________________________________
> 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
10:42 a.m.
+1 for Sass
On November 27, 2013 at 7:20:32 AM, Corinne Krych (corinnekrych(a)gmail.com) wrote:
Thanks Jay for giving us feedback.
+1 on building on existing website
To fit color code from Hylke, we need to adjust the light grey, pastel colour we used for
more contrasted colours.
Thinking ahead about this colour revamp, I've delved into CSS preprocessor. I think
aerogear.org would benefit using one:
- with help of variable, changing colour, size etc.. is made easy. Help defined color
palette.
- with @media and mixin, responsiveness is made easier to maintain
- and much more.. the good thing is you can apply/create mixin as you go and refactor in
iteration
I've done a first trial with SASS on that branch [1].
Similar work a bit less in details though with Sylus [2].
Choosing which preprocessor to use is like choosing which color fit you well.
I personnally go for Sass. I like its maturity, strong community. Latest addition Scut [3]
has interesting set of mixins. I was impressed by sass reverse engineering command that
let you move your CSS to sass file. it works like a charm.
My second choice would be Stylus. As we're using some Topcoat's component (menu).
Last option is Less.
Here a presentation I'll give next Thursday on preprocessor topic [4].
Let's move forward, if Hylke can pick colour on we could start with revamp colours +
CSS precporcessot
Then add some refactoring on main page content. I'd like to break it down into several
JIRAs to avoid too big PRs syndrome.
wdyt?
++
Corinne
[1] https://github.com/corinnekrych/aerogear.org/tree/sass#building-css
[2] https://github.com/corinnekrych/aerogear.org/tree/stylus
[3] http://css-tricks.com/introducing-scut-new-sass-utility-library/
[4] http://corinnekrych.github.io/preproCeSSor/
On Nov 25, 2013, at 3:41 PM, Jay Balunas wrote:
> Hi All,
>
> I'm just going to reply to the original email. There has been some good
discussions in the thread though and for the most part I agree with other emails.
>
> Most of my comments will be inline, but in general:
>
> I like the idea of using colors and lots of your ideas around APIs, doc areas, etc...
My main concern is about drastically changing the current site as we've had several
redesigns ( a couple before you came, and then you last one, and this proposed on).
I'd like to make sure we explore integrating some of your ideas, but keeping core
aerogear.org site mostly intact. So lets work on color scheme's, content updates,
API/coding presentations, etc... within the context of the current site if at all
possible.
>
> On Nov 4, 2013, at 10:24 AM, Hylke Bons wrote:
>
>> Hey everyone,
>>
>> So Jay asked me to look at how the website content is structured and how
>> to improve it. Since we have so much content, it gets confusing very
>> quickly.
>>
>> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>>
>> Here's a mockup of a possible solution. I'm better at explaining things
>> in pictures than in words, so please have a look. I'll explain things in
>> more detail below.
>>
>> I've tried to keep every subproject use case based, and explain the use
>> case before features. See this as a bigger picture, and don't focus on
>> the graphic design too much, it's there to help explain the structure of
>> the project, and is not necessarilly a final graphical design in any way
>> (though if you like it we can make it work!), but I wanted to show how
>> different colour palettes can help explain the project and give a better
>> sense of where you are on the website.
>
> As I mention I really do like the color coding, and especially being use-case driven.
I also agree with corrine that on the home page I'd like to make sure we keep the
platform icons (I like those a lot as well), but perhaps work in use-cases (below, above,
etc...), or use case drive in the sub-pages?
>
>>
>> I've done a lot of research on the project, but some things may be
>> wrong. So your feedback on that would be greatly appreciated. Even after
>> spending many months with the project, I still don't fully grasp
>> everything (which shows part of the problem).
>>
>> 1. Naming
>> I've split up the project into three main subprojects: "AeroGear
Core",
>> "AeroGear Push", and "AeroGear Security". These three are the
main focus
>> and use different icons and colour codings throughout the website to
>> guide people. Each subproject has "client" and "server"
components.
>> Server pieces being appended by "Server Component" and may be
standalone
>> or an addin to something. Client (API) pieces follow
"Project.Namespace"
>> format. This way, there's never any confusion about what we're talking
>> about in the documentation and marketing materials.
>>
>
> +1 on color scheme - and agree with server/client aspects of each. We really have 2
matrixes here; platform (iOS, Android, etc..) & feature (use-case) perhaps there is a
paradigm or structure to showing both somehow?
>
>> 2. Documentation
>> Splitting up documentation. "documentation" can be a broad term. I
>> suggest splitting it up in three parts to easily find what you're
>> looking for: "Setting up" (downloading and boatstrapping a dev
>> environment), "Examples" (how to use the API in your environment to
get
>> started), "API Documentation" (speaks for itself), and
"Tutorials"
>> (setting up more complex environments and API usage). This covers most
>> of the documentation that is currently on aerogear.org and will make it
>> a lot easier to browse.
>
> +100 our doc sections needs a good cleaning, organizing, and a better way to navigate
and view.
>
>>
>> 3. Coding languages
>> Where the API is unified across all platforms (hopefully most of it), we
>> can generalise example docs, and show a switcher for code blocks that
>> shows how to do a certain thing in a particular language using the
>> AeroGear API.
>
> +1 I like the idea of common docs, with some context switch ability to shift
platform. This will not always be possible but I think it could be on many of our
features. It might also help point out issues or mis-matches between libraries.
>
>>
>> 4. 1:1 mappings
>> I'd like to see the iOS, Android and Javscript APIs be self-contained
>> things that you can just drop in and use, with 1:1 mappings (what you
>> get on Android for a (sub)project, is what you get on iOS). There could
>> be technical reasons why these things are split up the way they are now,
>> let me know if so. I could be totally wrong on this too.
>
> As above there is not always a 1:1 mapping.
>
>>
>> Missing pieces:
>> - Where do we fit in Cordova?
>
> As Erik said - Cordova is a another core platform and should be featured.
>
>> - AeroGear Auth, Controller?
>>
>> These are things I'm not sure yet how they would fit in the proposed scheme.
>>
>> I think this is a step in the right direction, and I really hope it is
>> helpful. Let's iterate on this. Let me know what you think and how we
>> can improve. Looking forward to hear your opinions on this.
>
> Good stuff Hylke, and sorry for the delay getting back to you!
>
>>
>> Thanks,
>>
>> Hylke
>> _______________________________________________
>> 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
--
abstractj
4:57 p.m.
Hi Jay,
On 25/11/2013 14:41, Jay Balunas wrote:
Hi All,
I'm just going to reply to the original email. There has been some good discussions
in the thread though and for the most part I agree with other emails.
Most of my comments will be inline, but in general:
I like the idea of using colors and lots of your ideas around APIs, doc areas, etc... My
main concern is about drastically changing the current site as we've had several
redesigns ( a couple before you came, and then you last one, and this proposed on).
I'd like to make sure we explore integrating some of your ideas, but keeping core
aerogear.org site mostly intact. So lets work on color scheme's, content updates,
API/coding presentations, etc... within the context of the current site if at all
possible.
What do you mean exactly by "core aerogear.org"? I'm not really sure if
you're talking about the graphical design or the structure here. I'm
assuming the latter, just making sure.
As I mention I really do like the color coding, and especially being
use-case driven. I also agree with corrine that on the home page I'd like to make
sure we keep the platform icons (I like those a lot as well), but perhaps work in
use-cases (below, above, etc...), or use case drive in the sub-pages?
> I've done a lot of research on the project, but some things may be
> wrong. So your feedback on that would be greatly appreciated. Even after
> spending many months with the project, I still don't fully grasp
> everything (which shows part of the problem).
>
> 1. Naming
> I've split up the project into three main subprojects: "AeroGear
Core",
> "AeroGear Push", and "AeroGear Security". These three are the
main focus
> and use different icons and colour codings throughout the website to
> guide people. Each subproject has "client" and "server"
components.
> Server pieces being appended by "Server Component" and may be standalone
> or an addin to something. Client (API) pieces follow "Project.Namespace"
> format. This way, there's never any confusion about what we're talking
> about in the documentation and marketing materials.
>
+1 on color scheme - and agree with server/client aspects of each. We really have 2
matrixes here; platform (iOS, Android, etc..) & feature (use-case) perhaps there is a
paradigm or structure to showing both somehow?
If all libraries work on all platforms then I don't we don't think we
need something like this (we just need to mention which platforms are
available). If not, then yes, we need to somehow present that in a way
that doesn't conflict with the bigger picture. This is what I meant with
the library-platform mapping. As said, I' not really at home with all
the libraries.
> 2. Documentation
> Splitting up documentation. "documentation" can be a broad term. I
> suggest splitting it up in three parts to easily find what you're
> looking for: "Setting up" (downloading and boatstrapping a dev
> environment), "Examples" (how to use the API in your environment to get
> started), "API Documentation" (speaks for itself), and
"Tutorials"
> (setting up more complex environments and API usage). This covers most
> of the documentation that is currently on aerogear.org and will make it
> a lot easier to browse.
+100 our doc sections needs a good cleaning, organizing, and a better way to navigate and
view.
I'm so glad you agree with this! Apart from the subprojects presentation
I think this is the point on which we can benefit the most. I already
saw Erik has made some great headway this. Also, it's probably the
biggest task ahead of us site-wise...
> 3. Coding languages
> Where the API is unified across all platforms (hopefully most of it), we
> can generalise example docs, and show a switcher for code blocks that
> shows how to do a certain thing in a particular language using the
> AeroGear API.
+1 I like the idea of common docs, with some context switch ability to shift platform.
This will not always be possible but I think it could be on many of our features. It
might also help point out issues or mis-matches between libraries.
> 4. 1:1 mappings
> I'd like to see the iOS, Android and Javscript APIs be self-contained
> things that you can just drop in and use, with 1:1 mappings (what you
> get on Android for a (sub)project, is what you get on iOS). There could
> be technical reasons why these things are split up the way they are now,
> let me know if so. I could be totally wrong on this too.
As above there is not always a 1:1 mapping.
Can we figure out a list which these are?
This way I can figure out how we can present the exception without
distracting from the bigger picture.
> Missing pieces:
> - Where do we fit in Cordova?
As Erik said - Cordova is a another core platform and should be featured.
I'll
be on that.
> - AeroGear Auth, Controller?
>
> These are things I'm not sure yet how they would fit in the proposed scheme.
>
> I think this is a step in the right direction, and I really hope it is
> helpful. Let's iterate on this. Let me know what you think and how we
> can improve. Looking forward to hear your opinions on this.
Good stuff Hylke, and sorry for the delay getting back to you!
Sorry for the delay as well. ;)
Thanks,
Hylke
> Thanks,
>
> Hylke
> _______________________________________________
> 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
3748
days inactive
3826
days old
15 comments
6 participants
participants (6)
-
Bruno Oliveira -
Corinne Krych -
Erik Jan de Wit -
Hylke Bons -
Jay Balunas -
Summers Pittman