> … choice between better docs and better UI, I’ll choose a better UI every time
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. When i've started this whole new Admin UI thing, my intensions were primarily to make it look like it was from recent times and not a century ago. Afterwards Upayavira joined in to upgrade the frontend architecture to the current state of art - which by now didn’t help as much as we’d expected for others to contribute. I’m running out of ideas what else could help. We are here in backend country and not that attractive for capable frontend developers. We both came up with whatever we could - neither of us is a designer, at most a random guy with two eyes. In certain situations i’m the same as you, i’m the first person to critize this and that - i often see what others could improve, but as often i do not realize that i could do the very same for projects where i’m involved. and that’s for a variety of reasons. To sum it up: if you (again, as well as others) do not speak up - our hands are tied. of course it’s easier to report a specific bug that gets fixed, but nobody said it’s the only thing you can do. as helpful and needed it is to have people working on the documentation instead of contributing code - as important are suggestions on the ui itself. you don’t have to actually do it, especially not if it’s an area where you can’t help .. but you are one of many using it day in, day out. And that goes for all the things .. wordings, usability as well as and especially design. the ui still looks like (actually is) my first work-in-progress draft from years ago - and the reason therefore is certainly not because we all love it to death and refuse the change the smallest bits. those were a bit more than my two cents, but they needed to get off my chest. -Stefan On September 16, 2016 at 5:56:34 AM, Aaron Greenspan (aaron.greens...@plainsite.org) wrote: > Hi again, > > My two cents: I’m glad to see the discussion over improved documentation, but > if you give > me a choice between better docs and better UI, I’ll choose a better UI every > time. If contributors > are going to spend real time on the concerns raised in this thread, spend the > time on making > the software better to the point where more docs are unnecessary. All sorts > of things > could improve that would make the product far more intuitive (and I know, > there are probably > JIRA entries on most of these already…). > > - The psuedo-frames in the web UI are the source of all kinds of problems, > with lots of weird > horizontal scrolling I’ve noticed over the years. It makes the Logging screen > in particular > infuriating to use. When I click on certain log entries an arbitrary-seeming > "false" > flips to "true" under the "WARN" statement in the Level column. But on other > log entries, > it all just goes haywire all over the screen because it’s too big both > horizontally and > vertically, and then re-condenses as though I’d never clicked, as I mentioned > before. > > - The top menu on the left is in plain English. The core menu on the bottom > is written as though > it’s being viewed by a person who only speaks UNIX. For example, there is no > space between > "Data" and "Import" in "DataImport" and "Segments info" could just be > "Segments". Is > "Plugins / Stats" two menus in one? > > - "Ping" in the menu takes you nowhere in particular and shouldn’t really be > a menu item. > It should be part of the main dashboard with all of the other tech stats > (which I do like) > or a menu called "Status". (Why would one core ping faster than another > anyway? If this > is really for "cloud" installations where cores can be split up on different > servers, > why am I seeing it when everything is local and immediate?) > > - On the Data Import page, the expandable icons are [-] when they’re expanded > and still > [-] when they’re collapsed. Extremely confusing. > > - The Data Import UI makes no mention anywhere of the ability to import from > MySQL, which > is 99% of what I want to do with this product. It doesn’t tell me how to set > up the MySQL connector, > doesn’t give me a button that turns it on in some modular fashion, doesn’t > tell me if the > server connection is successful, doesn’t let me easily enter or edit > credentials, doesn’t > let me edit my queries anywhere, and doesn’t let me test out a new query and > see how it might > fit into the Solr schema. These deficiencies are presumably also true for any > database > data source, e.g. Postgres/DB2/ODBC/whatever—which also are not listed, were > I curious > to know what Solr can do just by looking at the product itself. > > - Nor does the Data Import UI have another section for picking a folder on > the filesystem > that might contain PDFs I want to import with Tika. > > - There is no field picker on the Query screen, but I just spent all of that > time defining > my fields in those XML files I can’t edit or auto-generate through the UI. > That means I > have to do extra work to remember them all. But then there is a field picker > on the Analysis > screen? > > - How do I restart Solr from the UI? Or change memory allocation settings? > Can I? > > - How do I change the port the UI is running on from the UI? Or limit the IP > addresses Jetty > is binding to? Can I? > > - How do I change log settings through the UI? Can I? > > - For those places where technical terms really are necessary (and I’d argue > that should > be nowhere), tooltips should be pervasive to explain what everything means. > q? fq? fl? > df? > > - The Data Import UI currently broadcasts your MySQL database password to the > world for > whoever is logged in. In a best-case scenario, the legitimate user might have > search > admin permissions but ideally not full MySQL permissions. In a worst-case > scenario, > they’re a random stranger who used nmap to find an open port 8983 and just > got closer to > rooting your server or at least taking all of your data. This feature—showing > the password—seems > unnecessary. Though I take issue with the kludge of shoving a configuration > file in an > IFRAME or something like it in the first place, while it’s still part of the > product, at > least replace whatever comes after the string "password=" and before the next > space > with some asterisks. > > - The Data Import UI always checks the "clean" box by default, which means > every time I > try to do something I almost erase my entire core, which takes a full day and > a lot of CPU > cycles to rebuild. I know this has been in JIRA for some time, and it’s still > not fixed. > And it’s a bug that destroys data! > > - Revealing my true ignorance here, I have no idea how to use the Analysis > screen. > > - The Files screen doesn’t say the name of the parent folder at the top, so > it’s not entirely > obvious where I even am on my filesystem or why I want the ability to view, > but not edit, > files through the browser. > > My general feeling is that the UI does mostly things I don’t understand or > want, and not > the few basic things that I do want. Even with a great sample environment, > this would still > be true. This is why the documentation ends up being so important. Again, I > would point > everyone to successful server products that are already out there that have > done similar > tasks well for decades now. If you don’t like WordPress, or the now aged > Netscape Enterprise > Server, then there’s phpMyAdmin, Oracle Application Server, Microsoft IIS, > etc. They > all have web UIs that are for the most part self-explanatory. Good software > doesn’t force > users to learn how it works. It hides the inner workings under the interface, > so that people > never even have to worry about it at all. > > Aaron > > PlainSite | http://www.plainsite.org
