> I thought my customers needed one thing (a fancy database), when they actually needed something entirely different (importing and exporting from Excel sheets). I made a rough prototype of the software as a first pass, with no backend data system, showed it to teachers, and got some feedback. This saved me hours and hours of work on a product feature that nobody but me actually wanted.
It may be worth noting that SQL and Excel are not necessarily mutually exclusive choices as the backend database:
1. The customer's requirement of being able to import/export from/to a spreadsheet document is a problem of interopability, rather than the choice of storage medium. Thus, you could as well just make use of your go-to database solution and implement synchronization separately—either by using RDBMS as the primary source or using it only for indexing/durability purposes—and the customer would still be happy.
2. Some spreadsheet softwares like Excel and Google Sheets allows you to query spreadsheet data in SQL (e.g. Microsoft ODBC) or some SQL-like language (e.g. Query Function). That said I haven't actually used them in practice, so I cannot guarantee how well it goes with actual pre-formatted or semi-structured data found in many spreadsheets.
Interopability allows a system to be complemented by the environment composed of other existing systems. The system might not need to interop, but only if it could satisfy every need originally served by pre-existing systems for the user. In general it's best not to assume which database backend should be used as the source of truth (cache or indexing is okay) if you are not the one in control of the data.
It may be worth noting that SQL and Excel are not necessarily mutually exclusive choices as the backend database
I think this is correct, and I'd love to get to the place you describe in the longer term, where spreadsheet IO and a separate backend DB can cohabitate peacefully.
I have a vision for what that looks like, but I'm going to have to develop the chops to get there. I'm still very much in the "rough prototype" phase, in no small part due to the limitations of my own skillset.
>>People make mistakes - like selecting the wrong buttons - and need to clear them sometimes. Include a “Clear Selections” button!
And that's what I hate about most software, especially in some critical applications, like applying for Visas (VFS is a serial offender that should be banned from civilised society) -- bad software is so unforgiving, so judgmental, make the smallest mistake and in VFS case, it wipes out all the data you typed and forces you to start again (and sometimes randomly crashes in the middle of typing). At one point I thought it would be easier to just cancel my trip rather than fight the website (and they dont take paper applications anymore , because... technology).
The chances of an app being crazy and buggy are directly co-related to how critical it is -- so while the teachers app talked about in the article is well designed, it isnt critical, since teachers can always do the work otherways. Meanwhile VFS and other government mandanted monopolies, for which there are no alternatives, are buggy as hell.
Is there an internet law for this effect? If not, I'd like to name one :)
Monopolies in general are like this I've found. Go to a cafe in a large park and it usually has little variety, high prices and terrible service. Why improve if nobody else can replace you and you can't go out of business?
> Adding hover-over alt text on a radio button form
"Alt text" is text that isn't seen but serves the same purpose as what is seen for people with visual impairments (and web indexers).
What you're describing sounds like a "tooltip." Maybe it would be even better to have it displayed all the time instead of mouse hover (no mobile device users without a cursor to hover with?)
You're correct - "tooltip" is the correct word here.
Maybe it would be even better to have it displayed all the time instead of mouse hover
I started by displaying it all the time, but the form got unusably cramped.
no mobile device users without a cursor to hover with?
My software is solely for desktop users, by design. No teacher I have ever spoken with engages in this kind of work on their mobile phones. I had a user laugh at me during an interview for suggesting it. XD
It sounds like the product lets them create a "bank" of reusable text. Certainly you'd want a proper keyboard for adding a lot of content to it but once that was done, part of its benefit is to reduce typing, making completion of a card on a mobile device more feasible.
If the task involves a lot of bouncing back and forth between your thing and something else (like a school's student information system), yeah, only a desktop OS will do.
I appreciate the suggestion, but there is zero input from my userbase that suggests that making this work on a tablet would have positive ROI in terms of engineering time. Most teachers I've spoken to simply don't use tablets. (Based on my research, few of them even own tablets.)
Great post. I found it entertainingly ironic that a post about a tool which reuses text blocks the half paragraph about Excel being the most popular backend database is repeated twice. I guess it was really important.
It may be worth noting that SQL and Excel are not necessarily mutually exclusive choices as the backend database:
1. The customer's requirement of being able to import/export from/to a spreadsheet document is a problem of interopability, rather than the choice of storage medium. Thus, you could as well just make use of your go-to database solution and implement synchronization separately—either by using RDBMS as the primary source or using it only for indexing/durability purposes—and the customer would still be happy.
2. Some spreadsheet softwares like Excel and Google Sheets allows you to query spreadsheet data in SQL (e.g. Microsoft ODBC) or some SQL-like language (e.g. Query Function). That said I haven't actually used them in practice, so I cannot guarantee how well it goes with actual pre-formatted or semi-structured data found in many spreadsheets.
Interopability allows a system to be complemented by the environment composed of other existing systems. The system might not need to interop, but only if it could satisfy every need originally served by pre-existing systems for the user. In general it's best not to assume which database backend should be used as the source of truth (cache or indexing is okay) if you are not the one in control of the data.