Ok so first feedback. Launched app. Went to create a new table. Entered name : "users". Got error "Invalid name". Got confused, whats illegal about the name. After some time figured out that name must start with UPPER case latter.
This could have been the error message instead of generic "Invalid name".
True, this could be improved. Note though that if you hover over the text entry box, there is a tool tip that says this:
Name of the field. Must begin with an uppercase letter followed by further letters, digits or underscore characters. Non-ASCII letters like German umlauts are not allowed.
Let's take a look at how the big boys handle something similar...
SELECT * FROM logs WHERE KEY = 'blah' LIMIT 10;
/* SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'KEY = 'blah' LIMIT 10' at line 1 */
I think there is some expectation of technical literacy for the use of a database. This would include being able to familiarize yourself with naming conventions and keywords.
I have personally never seen a database that gives detailed error messages like was requested and I'd be excited to see an example.
Yes, the error messages of modern SQL databases suck. On that note, SQL itself sucks (the two problems might be related). But that's no excuse to not do better. Besides, BeeBase seems more user-focused than MariaDB, presenting itself as a nice GUI tool. "Real developers" might not need good error messages, but they also don't need a GUI and would sooner use some unholy bash-sed-awk-Perl mixture.
Fair point. Databases encoding queries in JSON get some error messages for free, at least when it comes to "syntax". But I think even others do well.
I just logged into Grafana and tried writing a simple query. Upon failing I got a reasonably detailed and specific error message: 'parse error: expected type range vector in call to function "rate", got instant vector'.
I also tried XQuery in Xidel and it gave me nicely descriptive responses to whichever mistakes I introduced.
I'm all for RTFM, more than most, but this is a ridiculous take.
The software obviously did a specific check that failed, but added no context as to why. Like a boolean isValidName() function. You're already doing checks, you know why it failed, tell the user. Even in fuzzy terms is more helpful than pass/fail.
Now, if the error said something to the effect of 'name must be uppercase' and the user was confused or complaining, I'd be more inclined to agree.
The difference is providing a short succinct message that is either familiar or can be looked up as rg does here, vs vaguely saying invalid name without saying why.
It worsens the UX for no reason.
As a sibling comment said, the program already knows why the name was invalid. It would have cost nothing to surface the reason when reporting the error.
I'm not arguing that I think "Invalid name" is a good message here. I don't think it is. But if you're relying on either familiarity or the ability to look it up, then you're still relying on there being a manual to provide that information in the first place if it is not somehow included in the error message itself. As would be the case here with Bee and rg.
The equivalent of BeeBase’s error in your example would be simply “invalid regex”, which I’d say is still more useful as regex is widely understood and there are many tools that you can give regex to that will tell you what is wrong with it.
No, there's a specificity to "name" and "group" that makes them similar, which is one part of why I settled on this example. The other is that I expected the recipient to have experience with regex and find the example dumb, confirming my position that one can very well demand a basic knowledge of the tool that isn't immediately communicated by it.
Like knowledge of the regex language, or having spent ten minutes skimming through the tutorial part of a PDF manual.
In my experience, how to use a manual is a technique more widely understood than regex. Maybe this impression is wrong, I'd welcome something tangible pointing in another direction if it is.
It's not about a user, it's about someone declining to become a user because the manual is distributed as a separate PDF. I see two solutions for this problem, either use another software or hire someone to adapt this one to you.
As a user you know the basic constraints on table names, if you don't you can't use the software.
If your users are developers, then this mindset will inevitably lead to poor developer experience (DX). That is a stance that someone could take, but their software would be then only used in spite of the DX, not because of it. In general, this would lead to a more miserable experience. I don't think that's good, even if it's just a lot of small annoyances along the way.
Yeah, people have been having miserable experiences with this software and its predecessor for decades but still keep at it, they must be a lot less smart than you.
Comments like this are the reason why I will not touch software like this. I can live with the old school-style and the limited ability set sold on the webpage. But someone bringing up a legit complain and then receiving such hostile behavior, speaks for a toxic community or user hostile developers. And it's not limited to this one comment, but there are several collect here.
The replying comment side stepped the discussion of error messages lacking context that could be easily remedied to be identifiable and the response was "it's in the manual". All error messages meant to be understood by humans should be in the manual at minimum, but what the replyer suggested by ignoring the conversation was "your issue with the error message isn't important because you can figure it out yourself". It's dismissive to respond to nuanced articulated opinions made in good faith with simplistic matter-of-fact answers that don't address the problem, which could easily be seen as a form of hostility in a place meant for discussion and engagement.
You could argue that's not their intent or that it's the case of direct wording than intentionally being curt, but this is the second post in the chain that dismisses the legitimate discussion with additional redress to make sure you let the poster know that it's their problem "punching at shadows" and that their problems are imagined. What a shameful display of lacking empathy.
It's not important because there are many quirks to this software, including a Lisp-like programming language. Learning to use it involves internalising many things that aren't common knowledge, which one has to figure out by trial and error, and the manual.
If you are seriously interested in BeeBase you'll be spending hours learning the basics of the Lisp-dialect and GUI toolkit, getting a hangup on that error message means you don't have that kind of interest. Maybe the empathy got in the way of that, I don't know.
And let's say someone makes a patch that implements a new error message that specifies which of the two rules regarding table names has been breached, then what? More complaints about the next quirk? Some other error message? Begging for a Lua-implemented query language because parens lost the syntax wars of yesteryear, describing it as miserable that it isn't already integrated?
> And let's say someone makes a patch that implements a new error message that specifies which of the two rules regarding table names has been breached, then what? More complaints about the next quirk? Some other error message?
Yes, this is how software development is done, assuming you like your customers.
I was quoting you, using the > sign to refer to what you said directly. I thought the quote was useful to highlight that it can be easy to have a mental disconnect, or even an antagonism, between developers and their stakeholders.
The people who use the software of the people who write the software. If the word "customers" is triggering, the argument holds just as well as for "users".
Why are you dodging the question? Who are you talking about, and why?
It's not the commenters above that complained about the error message, they aren't users and highly unlikely to ever become users. Instead you've brought in some unspecified other for unspecified reasons.
Yeah there’s a lot of people mistaking bluntness for hostility here.
And, at the end of the day, this is a free open source piece of software. The experience could be improved, definitely, but nobody owes it to anyone to do so and it’s important to remember that as well.
This could have been the error message instead of generic "Invalid name".