Live data from Hacker News

Why Enterprise Software Sucks

twitter.com

421–430 of 570 posts

Re: Why Enterprise Software Sucks

#421
post #380

Earlier quoted context omitted.

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…

> 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

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?

Re: Why Enterprise Software Sucks

#422
post #401

Earlier quoted context omitted.

Keyboard. Touch sucks for writing.

I’ve never had any trouble with typing on a touch screen just as fast as my old Blackberry. Especially if you have autocorrect.

Autocorrect is more often slowing me down. It's only rarely correct.

Re: Why Enterprise Software Sucks

#423
post #380

Earlier quoted context omitted.

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…

> 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 b…

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.

Re: Why Enterprise Software Sucks

#424

I write enterprise software for fortune 100 companies. If I put myself in the user’s shoes and had an alternative, I’d most likely uninstall what we built and jump ship. But they can’t. It’s an internal app and the user is forced to use it. I try and fight for what’s right but if I had a dollar everytime I heard “ we aren’t google/amazon” , “only xx people will use it”, “we are just doing this to get off the old tech…

> UX isn’t valued Good UX drives costs down for training and draining of human capital. That should be the pitch. Next question, who in the fortune 100 should hear that pitch?

Maybe the world has changed now, but around 2006/2007 I was an embedded software engineer for a company that built public transport smart-card ticketing systems.

I was working on a device that sat on a bus, operated by the driver. It had a monochrome screen with something like 640x480 resolution and around 16 or 18 buttons.

One of the things the bus drivers needed to do was to sell tickets, but the number of buttons they needed to press to sell a ticket was like 10 or 12 when I started working on the software.

I explained to our project manager who was in charge of the delivery that I could improve things to reduce the number of button presses to around half that amount, and it be much more usable for the drivers.

She told me very sharply that I was never allowed to improve the software in any way by my own decisions. The only kind of improvements to UI/UX (which was not even a term back then) was after the customer requested it, because then my company would try to file it as a "change request" rather as a "bug" because that way they could squeeze more money from the customer.

The flip side of that argument was that the company all too frequently would accept a loss on the main contract in order to win the bid (working in the public sector and all), and then have to earn money on all the change requests. It was one of the specific responsibilities of a project manager back in those days to drum up as many change requests from the customers as possible.

It was horrible and I'm glad I don't work there any more, but I can sympathize with the problems from both sides of the aisle.

Re: Why Enterprise Software Sucks

#425

Earlier quoted context omitted.

> 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!

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

Re: Why Enterprise Software Sucks

#426

Earlier quoted context omitted.

Half of the people I know who love Excel in that way would now be making significantly more money if they didn't. These people fall into two groups: The spreadsheet jockey who just likes doing cool things with the data. Excel is just powerful enough to satiate this guy long enough for him to fall out of the habit of rethinking his workflow. If he had moved on earlier he'd be a DBA or a data scientist by now. The othe…

You said "half of the people.. would be making significantly more" and then proceeded with further grouping. I assume the subgrouping applies to that same half? The other half of folks are quite successful hedge fund, private equity and consultancy partner types, and I suspect those folks would not be making significantly more money if they had stopped using Excel and invested time in becoming DBAs, Data Scientists o…

Yeah, perhaps I should have been explicit about the fact that for some people it's absolutely the right tool for the job. My mom loves it, it serves her well, and her use cases don't require her to go beyond its capabilities.

But if fully half (admittedly a subjective assessment on my part) of a tool's users would be better served by not using that tool for one reason or another--that's a pretty significant subset.

Re: Why Enterprise Software Sucks

#427
post #380

Earlier quoted context omitted.

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…

> 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 b…

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.

Re: Why Enterprise Software Sucks

#428
post #17

I used to work in support at a big company. We went through endless Salesforce resigns with folk's who don't use them all making decisions and patting themselves on the back for each redesign. It was horrific as a user experience, everyone is a UI expert and had an opinion based on this one time a thing happened... 3 years ago... In fact most every decision was made dude to some anecdotal incident where the person wh…

CRM products tend to be super easy to customise, so they often end up a complete mess simply because it is so easy to add or change stuff.

Yeah it is a huge issue with CRM products.

Granted any product with lots of customization can do that, but CRM products really seem to lead the pack in terms of huge clusters of OMG.

Re: Why Enterprise Software Sucks

#429

Earlier quoted context omitted.

And yet neither Android nor iPhone today as as good at doing email as Blackberry was 10 years ago. They do lots of other things a lot better, but email? Nope.

What did blackberry do so well in email?

For me and for a number of email "power users" whom I know, Blackberry strictly dominates iPhone email experience.

Stipulated, it definitely depends on personal preferences and workflows as to what you personally prefer.

But it is pretty incontrovertible that Blackberry was a finely-honed email tool with departures from that core use case being pretty tightly defined around the things you do ancillary to email (setting appointments, reading attachments, etc.).

iPhone is worse at that particular thing -- but vastly more capable broadly speaking for a universe of other things.

Re: Why Enterprise Software Sucks

#430

Earlier quoted context omitted.

I always thought their killer feature was the fact that they'd operate on pager frequencies, so you could get an email (or at least a portion of it) in what was quite often a cellular deadzone. Largely moot these days between the proliferation of WiFi and LTE repeaters.

The BlackBerry phones didn’t operate on pager frequencies did they?

It wouldn't surprise me if the BB push notifications worked over pager frequencies. I can't find anything online about how they actually worked, but the original two-way communications device from RIM was called the "Inter@ctive Pager"[0]. If I were to guess, I'd say it is possible the push notification went over a pager frequency and included a snippet of the message. The device would then be able to request the full message over the cellular data network. The pager networks of the time were more robust (and travelled longer distances), so the BB would be able to received the notice of a message (and part of the payload) even in a cellular dead-zone.

But, that's just me speculating...

[0] http://www.braddye.com/newsletters/2010/n22jan2010.html

Post reply on HN