On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman <miburman(a)redhat.com> wrote:
Consumers is terrible word for any client, as they both consume as
well as
produce the data.
Well that was actually reflecting the current state, we have "things" that
feed data to the server and "things" that consume data from the server. The
client libraries provide an API to feed and consume.
For example for Heapster, we currently produce the data, however at
the
moment I'm creating a change that will consume the data from HWKMETRICS.
Integration / clients is far more used and known word, while
consumer/producer is something more specific and implies a design pattern.
- Micke
----- Original Message -----
From: "Alissa Bonas" <abonas(a)redhat.com>
To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, June 14, 2016 3:32:16 PM
Subject: Re: [Hawkular-dev]
Hawkular.org
On Tue, Jun 14, 2016 at 2:46 PM, Thomas Heute < theute(a)redhat.com > wrote:
On Tue, Jun 14, 2016 at 1:24 PM, Alissa Bonas < abonas(a)redhat.com > wrote:
1. I would put REST api as a separate section, and also not in the same
hierarchy/section as client libraries, because REST is part of the project,
and clients consume it.
I'm not sure, from a developer perspective it doesn't really matter if
REST is part of the project (except that you have nothing else to
download/use), but it should be clear what options, as a developer, you
have.
One has the choice between Ruby, Python, Go or plain REST.
At least that was my way of thinking.
2. Having sections named "clients" and "client libraries" can be
confusing.
Agreed.
Perhaps "integrations" or "applications that consume hawkular" is
better
for "clients"?
I thought of "consumers" for a short name. As we have "feeds" that
feed
data and "consumers" that consumed and display or do something with the
data. Still not convinced about that name though....
consumers sounds good.
3. Is there a section dedicated to community events
(meetups/conferences/hackaton/summit, etc.) where there are talks about the
project? Didn't see it in the diagram.
Good point.
We should probably splash them on the front page + blog.
4. Overview can link to quick start imo
Not sure what you mean, after one read the overview he should definitely
be invited to get started.
my point was that the navigation should be as simple and efficient as
possible. so if a user reads the overview page, there's no need to go
to the homepage again in order to go to "get started", but rather navigate
directly/have an inviting link from overview to get started.
5. What should be the difference between quick start and the download
sections?
Quick start explains how to install the quickest way and get something out
of the product.
The download section allows to find links of latest and previous releases.
like above, I would also link between quick start and download pages so
the user will get a convenient flow of "here's how to" and "here's
where
you can download from"
6. Ways to contact community? I saw only social links in the footer, but
what about mailing list/irc,etc.?
That would be in Community>Connect
p.s. I wrote an article couple of years ago on usability of community
websites, maybe some ideas from there would be helpful as well
https://opensource.com/business/14/8/open-source-project-front-door
I'll have a look, thanks !
Thomas
thanks,
Alissa
On Tue, Jun 14, 2016 at 1:25 PM, Thomas Heute < theute(a)redhat.com > wrote:
With the recent repackaging effort + the ManageIQ UI, we need to rethink
hawkular.org .
It's tricky to keep it simple, what to download, for what usecase... And
at the moment it's getting outdated.
IMO, it should be trivial for end users to figure out:
- What to download
- where to download and how to install the server
- find/browse/download the various options to feed the server with data
(WF agent, ptrans supported protocoles, ...)
- find/browse/download options to use/read the data: (ManageIQ, Grafana...)
and for the developers
- find/browse/download the client libraries (Ruby, Python...)
- Find client libraries documentation
- Find examples...
We should probably not separate/fork Hawkular Services from Hawkular
"community" too much, beside the installation procedure and few things that
we would mention as only available in the "larger" package. I use the term
"Hawkular Server" in the mind map for the 2 "flavors".
Please propose improvements to the draft attached that represents the
website structure. (A square is not necessarily a page, it may be a section
of a page)
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev