<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman <span dir="ltr"><<a href="mailto:miburman@redhat.com" target="_blank">miburman@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Consumers is terrible word for any client, as they both consume as well as produce the data. </blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>Why does it consume data now ?</div><div><br></div><div>Thomas</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Integration / clients is far more used and known word, while consumer/producer is something more specific and implies a design pattern.<br>
<br>
- Micke<br>
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
From: "Alissa Bonas" <<a href="mailto:abonas@redhat.com">abonas@redhat.com</a>><br>
To: "Discussions around Hawkular development" <<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>><br>
Sent: Tuesday, June 14, 2016 3:32:16 PM<br>
Subject: Re: [Hawkular-dev] Hawkular.org<br>
<br>
<br>
<br>
On Tue, Jun 14, 2016 at 2:46 PM, Thomas Heute < <a href="mailto:theute@redhat.com">theute@redhat.com</a> > wrote:<br>
<br>
<br>
<br>
<br>
<br>
On Tue, Jun 14, 2016 at 1:24 PM, Alissa Bonas < <a href="mailto:abonas@redhat.com">abonas@redhat.com</a> > wrote:<br>
<br>
<br>
<br>
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.<br>
<br>
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.<br>
One has the choice between Ruby, Python, Go or plain REST.<br>
<br>
At least that was my way of thinking.<br>
<br>
<br>
<br>
<br>
2. Having sections named "clients" and "client libraries" can be confusing.<br>
<br>
Agreed.<br>
<br>
<br>
<br>
Perhaps "integrations" or "applications that consume hawkular" is better for "clients"?<br>
<br>
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....<br>
<br>
consumers sounds good.<br>
<br>
<br>
<br>
<br>
<br>
<br>
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.<br>
<br>
Good point.<br>
We should probably splash them on the front page + blog.<br>
<br>
<br>
<br>
4. Overview can link to quick start imo<br>
<br>
Not sure what you mean, after one read the overview he should definitely be invited to get started.<br>
<br>
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<br>
to the homepage again in order to go to "get started", but rather navigate directly/have an inviting link from overview to get started.<br>
<br>
<br>
<br>
<br>
<br>
<br>
5. What should be the difference between quick start and the download sections?<br>
<br>
Quick start explains how to install the quickest way and get something out of the product.<br>
<br>
The download section allows to find links of latest and previous releases.<br>
<br>
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"<br>
<br>
<br>
<br>
<br>
<br>
<br>
6. Ways to contact community? I saw only social links in the footer, but what about mailing list/irc,etc.?<br>
<br>
That would be in Community>Connect<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
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<br>
<a href="https://opensource.com/business/14/8/open-source-project-front-door" rel="noreferrer" target="_blank">https://opensource.com/business/14/8/open-source-project-front-door</a><br>
<br>
<br>
I'll have a look, thanks !<br>
<br>
Thomas<br>
<br>
<br>
<br>
<br>
<br>
<br>
thanks,<br>
Alissa<br>
<br>
On Tue, Jun 14, 2016 at 1:25 PM, Thomas Heute < <a href="mailto:theute@redhat.com">theute@redhat.com</a> > wrote:<br>
<br>
<br>
<br>
With the recent repackaging effort + the ManageIQ UI, we need to rethink <a href="http://hawkular.org" rel="noreferrer" target="_blank">hawkular.org</a> .<br>
<br>
It's tricky to keep it simple, what to download, for what usecase... And at the moment it's getting outdated.<br>
<br>
IMO, it should be trivial for end users to figure out:<br>
- What to download<br>
- where to download and how to install the server<br>
- find/browse/download the various options to feed the server with data (WF agent, ptrans supported protocoles, ...)<br>
- find/browse/download options to use/read the data: (ManageIQ, Grafana...)<br>
<br>
and for the developers<br>
- find/browse/download the client libraries (Ruby, Python...)<br>
- Find client libraries documentation<br>
- Find examples...<br>
<br>
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".<br>
<br>
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)<br>
<br>
Thomas<br>
<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>