And, to be clear, this has nothing to do with "classroom".

The problem is people design these things without any sort of actual testing in actual conditions where the software is supposed to be used.

Displaying 5 results per page is a bug, not a feature. Having restrictions on filetypes is a bug, not a feature. The same could go on to the rest of their "features". (My biggest pet peeve is date formatting — just give me ISO8601 dates, please; HackerNews, you, too!)

At SXSW, there was a coffee-bot vendor. They didn't bother testing with an adequate number of folks, so, the whole thing overflowed on first day. Predictable? Yes. Would be noticed by a committee? Not a chance.

> just give me ISO8601 dates, please; HackerNews, you, too!

Strongly seconding. It's an annoying UX antipattern, especially as it loses precision over time ("28 minutes ago" is fine, but "yesterday" or "5 days ago" or - even worse - "2 years ago" is not; having the date specified to hours or minutes is actually useful, especially in context of a site with international audience). Doubly so on HN, which doesn't even bother with giving the actual date/time in the tooltip, which is the usual cop out (not an actual solution, since there are no tooltips on mobile).

Definitely agree about the loss of precision. It's also a problem for machine readability and SEO. The solution I like is using the HMTL5 <time> element for semantic markup of timestamps. If you do something like this:

    <time datetime="2019-10-11T13:53:36.861" title="Fri Oct 11 2019 13:53:36 GMT-0700">2 minutes ago</time>

Then you get what in my opinion is the best of both worlds: machine readable timestamp in the datetime field, human-friendly detailed timestamp as a tooltip (the title field shows when you hover over the element), and relative time as the default display. Bonus points if your React component or ERB template or whatever switches from relative time format to absolute for the inner text when the timestamp is older than a day or so.

"when you hover over the element"

On the website I'm looking at Google Analytics for right now, fewer than 35% of the visitors are from devices where "hover" means anything...

Well, it would require JS, but you could turn it into a button to show/hide an HTML tooltip or additional displays of the time. That iOS supports a mouse (in accessibility settings) or an Xbox controller but doesn’t properly support an “abbr” tag... it was acceptable in 2007 when we were happy to see the phone load nytimes.com with all its columns. It’s feeling very out of date in 2019, when 12 years later we’re adding downloads and “desktop safari” but we never finished the “desktop-equivalency” parts of the HTML5 spec. It would be amazing if Apple ported some of their iOS native components to web components or to enhance HTML5 elements. The farthest we’ve gotten so far are keyboard search button hints, if I recall correctly. Which is really quite disappointing, that an app made for jQuery UI would work as well as an app from today if you flatten and modernize the design, and add a bit of offline caching...

I prefer the HN method of 28 min, yesterday, 2 hours ago, etc... for HN. The older a comment or post, the less relevant it is to a particular discussion. This site is for real-time discussions of articles, so it is optimized for that use-case. The older a comment, the less relevant it is towards the immediate discussion. Thus, older comments have less precision, because those details don't matter for the discussion.

I'd expect a site/application that is designed for students to manage homework would have different date/timestamp requirements.

HN may be optimized for current discusions, but is also a repository of knowledge; I frequently land on years old threads from Google searches. For older times, an explicit ISO timestamp has at least two benefits: 1) I can compare it easily to other dates (e.g. is that comment older or more recent that event X, or software version Y), and 2) time of the day is a half-decent proxy for telling whether the US or Europe was awake then.

And while you can justify the inprecise stamp on HN, there's no excuse for GMail and a score of other messaging software doing the same. When I'm looking at the date of an old e-mail, I almost always need the exact date and time. "2 weeks ago" is useless. "2019-09-27 08:43" tells me it happened before work, on a day after an important meeting, etc.

ISO8601 date/time can easily be transformed into the fuzzy format HN uses, but not vice versa since the fuzzy format is lossy.

If HN sent dates to the client in ISO8601, the client could then transform that format into the format of their choosing with client-side javascript (either a userscript, or delivered to the user by HN.)

It's hard to be sure this isn't satire.

You mentioned 'for HN' twice in the same sentence.

Your 2nd, 4th, and 5th sentence all try to assert the same thing - older comments are less relevant than newer comments - despite there being no evidence, anywhere, that this is the case. Your 3rd sentence is partly true, though there's some historical record aspect to HN comment threads that you're discounting.

Your second paragraph is a non sequitur. Sites that correlate points in time with timestamps are ubiquitous, and there's rarely a compelling case for using wildly different approaches to displaying same.

They could easily do it the Reddit way and still provide a timestamp but keep the simplicity and relative time format. Just have it pop up the timestamp on mouse hover. That's still very simple and can be effectively done using just CSS.

You don't even need any CSS for that — the title attribute alone would be sufficient.

Personally I like HN the way it is. Very little UI clutter. If we start doing ISO dates and maybe options to switch between high precision and default low precision, we lose the good feel that HN has produced.

I'd prefer both.

I have one word to tell you: timezone

What about them? ISO8601 supports time zones.

> The problem is people design these things without any sort of actual testing in actual conditions where the software is supposed to be used.

I’ll do YOU one better. </Drax>

I work in an industry where software is still created by good, old-fashioned, by-the-book waterfall process, by outsourced developers. You know: the industry-proven, rock-solid, 20-year-out-of-date, slowest-and-least-agile methodology. Not only do the people who write the software never use it anger, they have no clue what the software is supposed to actually be doing. They don't understand our product, don't understand HOW these KINDS of products work, don't understand what engineers are doing TO the products, and don't understand what would be useful to have from software to help DO that. How many steps removed from actually USING the software is that? Well, you can imagine the frustration that end users experience on a DAILY basis, with ALL the tools they're supposed to be using, both home-grown, and customized commercial.

Gee… I wonder why there are so many shared Excel workbooks functioning as ad-hoc database applications on the network drives…

The most damning part of this is that there were some studies done on our engineering processes in relation to our competitors, and the numbers were bad. Really bad. You would think that senior management would sit up, take notice, and connect the dots. But they don’t seem to be doing that, which leads to one of two conclusions, and neither are encouraging.

Sounds god awful. What industry do you work in?

I find it hard to understand how a business like this stays alive. Really, how?

I'd disagree a little, the problem is not testing, it's building the software in the first place when it doesn't solve a real problem.

This so much.

Sadly, what you describe as the anti-pattern is actually the industry standard.

And you don't have to go far to see examples — Slashdot and Reddit redesign come to mind. Both are unusable.

> Having restrictions on filetypes is a bug, not a feature.

It should be - but for many school IT security types it really is a feature to limit file types

I fought this during my entire teaching career.

Blocking file types by extension is pointless. as you can just change the file type.

If you're worried about kids being able to run arbitrary python scripts on your network, then the security problem is not the kids, it's your shitty network.

People are given cash as bug bounties for finding security flaws in systems, but in schools they are punished!

>If you're worried about kids being able to run arbitrary python scripts on your network, then the security problem is not the kids, it's your shitty network.

How is this even possible? Unless your CMS runs on python somewhere and does eval() a lot. Then yes, that is a huge problem. Moreover, why would that stop anything just not called .\+\.py?

If your CMS does `python ${fileIjustdownloadedfromuser}` in a shell then we are in serious trouble.

I think it's also a problem when people are rewarded for finding these kinds of bugs that are not actual bugs.

Some bad person vandalised an obscure public Oracle repository on GitHub that's not even for any public product they're known for (OpenGrok). Instead of being banned, the owners restricted public edits. WTF? It's small things like this that end up being having the anti-pattern become the norm.

Could not agree more!!!

What about security patterns for web browsing?

I feel the logic is somewhat similar but injections to websites / applications may be easier and hard to prevent against, so filtering pornography may be useful. I’m a dev not a security expert so sorry in the lack of understanding. I am actually trying to learn more about security / hacking

Security: it seems to me that in the wild, 40% of it is security theater, another 40% exists primarily to ruin your mood and control you the user, and remaining 20% is actually around the right trade-off between utility and safety.

I agree that it is mostly theatre. I understand not allowing an exe, but if you have to download the file and rename it, how much of that would be unintentional?

This reminds me how for awhile I was emailing myself .tar and .exe files through Gmail or school email systems by renaming them to .jpeg files.

Recent-ish (past year) Gmail patched this (for .tar at least), so I started using base64 encoded text files.

Now though I just pay for my own email service away from Google.

O365 blocks ps1 files by default. ps1 files aren't executable by default on any windows machine.

why is the vendor that makes the OS (MS) making these types of decisions?

Agreed, but trusting the extension at the end of the filename for this purpose screams, "amateur hour."

Extensions were important to filter when Windows explorer was still lacking rules to forbid file execution based on provenance, but was already defaulting to a) hide the file extension and b) display whatever pixels were embedded in an executable as the file icon. The combination of a) and b) was making even moderately security aware users utterly defenseless.

HN? Let Oracle and SQL Server databases start using that without one forcing them to. There's a long list of stuff to be bothered with before even looking at HN.

I work in a corporate environment and I also write software -- both external and internal tools. My intolerance to unnecessary pain is one of the main driving forces in creating software-based tools.

The amount of pain inflicted on employees by enterprise solutions of various kinds is immeasurable. As a developer, I squirm witnessing so much unnecessary work and discomfort associated with simple tasks.

For example, even in 2020, managing expenses is so painful that employees consider not expending their spending.

> managing expenses is so painful that employees consider not expending their spending

That's not a bug for some companies, who would prefer to not reimburse you.

Managing expenses is only a pain because my company doesn’t trust me when I tell them I spent $20 on a meal. And have to give them both a digital, and then physical (signed!) receipt.

It's annoying and could probably be made easier, but these things are required by law. Also, not everyone can be trusted and it's not easy to tell.

No, but there are solutions that involve giving people a fixed amount of money every month for these small expenses (or a fixed amount per day for longer business trips).

I would assume most companies use per diem for business trips. Agree that it would be great with something similar for other small expenses.

But none the less, all company expenses needs to be verifiable by some kind of receipt in the accounting to be legal. At least thats how it works in my country. So someone has to enter that into some sort of system, ideally the economy people would take care of that.

Definitely not. We require digital images only, and not even an image is required for corporate card transactions under a limit.

I agree with everything you say, except the last bit.

You can't believe people aren't aware that concur is a pita and hence it reduces expense valid expense submission...

Concur is a pleasure compared to some internal SAP-based expense reporting systems I’ve used.

Concur, especially on mobile is pretty good. It’s a lot better than every single project manager tool that I have ever used.

I adhere to "dogfooding": use what you make, and use it seriously. Then you'll understand what design documents so often fail to communicate. Programmers and certainly architects should get onto the work floor, and actually participate in the job, preferably before starting their "real" work, but certainly afterwards.

The unfortunate part with enterprise software, is that in the end its all bought on tender basis. Every minute the programmers and architects spend participating in the actual job, they do not spend creating new features. So your product will either have less features than the competition, or your product will cost more than the competition.

Dogfooding enterprise software is mostly impossible, since the people developing it are pushed to deliver features, because that is what administrators/managers use to choose between software. They don't care about usability, because it is not something tangible you can check.

I agree. It’s just hard sometimes if you don’t experience the problem you’re trying to solve in your daily life. How can I dogfood construction software if I’ve never worked construction? Get a construction job?

Who are you making the software for?

If it's your own company or a client, it's not too hard to get them to let you tag along with someone who will be using the software.

If you're launching a startup then you should have customers lined up before you start writing code. Ask them if you can watch them work to better understand how you can help them.

Most people are happy to share when you show interest in their work and it doesn't take much. A couple of days can really break your false assumptions and give you a good idea of what the workflow looks like. You can pick up on details like the order in which information is available.

It's worth doing more than once too, presumably your software is going save time and impact how they work so you'll need to refresh your knowledge.

The real problem is that the people who decide to use the software are not the ones actually using it. This is the problem with top down decision making. And this is why enterprise software often sucks

It's the same reason architects can't design biochemistry laboratories. And trust me, they're bad.

You could have automated this with a macro or program. Or given extra credit to students that did.

Have you ever used Instructure? My university uses it (I'm a student). It's really great on the student side and from what I've seen really flexible and easy to use from the teacher's perspective too.

Strongly disagree. Recently took a graduate level database management course, and using Instructure was one of the hardest parts of the course. Poor information flow, too many places to have to check for notifications, tasks, and basic information.