On 16 September 2016 at 18:30, Stefan Matheis <ste...@mathe.is> wrote:
>> … choice between better docs and better UI, I’ll choose a better UI every
> Aaron, you (as well as all others) are more than welcome to help out - no
> matter what you do / how you do it.
> While we’d obviously would love to get some more hands helping out with the
> coding parts - improving the UI in terms of wording (as you just pointed out)
> does help equally as much, if not even more.
And just to back it up with facts:
Let's run this query against my ugly-but-interesting Solr-to-Github
collection ( https://github.com/arafalov/git-to-solr):
That should be (approximately): "Give me breakdown on committer names
that committed more than 10 times something that includes a css or js
file. Limit this to last 5 years". And you'd get:
That's it... In last 5 years! UI design is hard. Especially when the
core developer team are the hard core backend guys. Solr only got the
Reference Guide (as opposed to WIKI) because LucidWorks did the bulk
of initial (and possibly ongoing) work. The pretty website was also
sponsored. We don't have in-the-team UI/HTML/CSS/JS expertise.
However, if you don't mind installing a third party project, Cloudera
Hue is a free (open-source if I remember correctly) interface to a
bunch of big-data components, including Solr. They do nice videos too:
Or there is a commercial one from LucidWorks themselves.
A lot more people know how to contribute to the documentation and
workflows around that are better. And hopefully will be better yet
again once the migration away from Confluence happens.
Or perhaps somebody will sponsor a full-blown front-end developer to
help out. Of course, _they_ not being a part of the current team would
need to figure out what is possible and what APIs to use. So
documentation would come useful there too.
Newsletter and resources for Solr beginners and intermediates: