Everything that Petric said.
Also, a few other things :
Backward compatible client.prefs fileI understand that the client.prefs file, when opened with a newer version of the client, has troubles being loaded by an older version afterwards. However...
This isn't a nice way to say it (and i'll come back to that later on). I highly doubt it is out of our reach to make client.prefs being automatically discarded when invalid, with a message saying "oops, client.prefs were broken, we discarded them, sorry". You could argue that "you're not supposed to downgrade your client", but in effect you are wrong : there are multiple reasons to downgrade your client. The latest version may be bugged (this will happen at least once). You may use different computers with different client versions. You may have multiple versions installed for testing. Etc, etc, etc.
My suggestion :
- Make client completly ignore unknown keys or parameters from the prefs file on loading
- If that is not possible, maybe structure the prefs file in a different way so that each key and parameter is stored by version number, allowing earlier versions to only load what's necessary to them
- If that is not possible, discard the file if there's any error loading it. Errors in the prefs should NOT prevent the client from starting.
- At least, make the error message readable. "Could not load your prefs. Details below :" is better than "Some error you need a computer science degree to decrypt occured".
Error handling, user-sideThis one is my biggest problem with Java client. When errors happen, they show up as undecipherable wall of texts, that you can dismiss but you have no idea what consequence that will have or what part of the client just failed (is that serious ? not ?) unless you start digging into the stacktrace.
There are, obviously, some errors that are going to be much more frequent than the others. Could not join the game. Could not connect the API. Could not load the coop leaderboards (I believe this one is already done). Could not host the game. Etc.
My suggestion is :
- Create a set of localized generic errors messages corresponding to each most frequent error code, allowing the client to say "Uh Oh ! Sorry, I could not open that replay because the file is corrupt ! More details below : <stacktrace>".
- Make the stacktrace HIDDEN by default, in a deployable menu like the [ spoilers ] from bbforums. Something you have to click on to expand the window and get the details of. Stacktraces are ugly and scary to the normal user.
Material design UI ?I had a discussion about this one with a few of you guys, and what came out of it is that I feel like it keeps being repeated that "Java client strikes for material design UI" even though no one seems to have even slightly researched what it is.
Let me repeat it further : The current java client is absolutely not designed the way a material design app should be.
This, to material design, is pure nonsense.
https://material.io/It's an obvious window layed out ontop of other content (which should never happen - such window with that much in it do not exist in material design), with a 90% opacity so you can still see what's behind (why ?).
Neither the select menus nor the buttons do respect any part of the chart. This should not be a window but a pane, and the Cancel button shouldn't even exist : but be a "<-" button on the top left corner. Java client is full of oddities like this. Take this for example :
What on earth is even going on ? I have not a single idea of where to look. What the java client makes me feel like is that you guys wanted to take a design chart to look serious, but eventually it didn't fit your needs (material design is mostly for web applications and mobile / touchscreen applications!!) and therefore you bent it in every way possible to make it still usable. When talking of the "Create game" window I was given as argument that it was a "dialog box" (short answer : it's not. In no way.) and that therefore it was okay. It's not.
The python client had a bad UI, but it was usable. The java client has a somewhat better UI, but in some places it gets ridiculously hard to understand what's going on.
Pick a design chart, or keep this one : but in anyway,
stick to it and don't lie to yourself. Imo, material design isn't a good pick at all for a client like this, and since the java client is very far from it anyway you could aswell discard it entirely and choose another one at this point.
Profile picture(how do I change my profile picture ? It's been since 0.7 I have this weird green thing and I can't change it)
(can the other users even see it at all ?)
(i like this feature but really it's weirdly handled)
The vaultAs someone fiddling with the java api all the time, I do understand the logic behind this camouflaged search bar. But you must think that the average user doesn't care about "Name" "Contains" "Value". It doesn't mean much.
It should be a giantic search bar, with a magnyfing glass logo or whatever, and the placeholer shouldn't be "Value" (???) but "Search...". Regarding the searched criteria (By Name, By Author, etc...) it should be part of a smaller SELECT button coming
after the search field and named something like "Search by". Taken as it is currently, the search panel is probably very powerful but oddly counter intuitive.
UnitDBStop breaking my CSS!
ChatNeed clear separation between the tab and the chat to understand what's going on.
Maybe lines to separate them ?
:mspaint_expert_avatar:
REVEAL!Reveal ? More like...browse ?
meep meep meep meepthe notification sound is awful! Maybe you could add the option to use a custom one ? Or maybe that could be part of the theme ?
That's all for me, for now, I think.
Other than what I mentioned, great work
It's overall much more usable today than it was 1 year ago.