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.
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.)
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.
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.
> 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.
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.
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?
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 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.
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.
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?
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
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.
I think this gets it wrong. The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining.
If you look at all of the most successful software of all time they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel, SAP, Photoshop, Salesforce, JIRA. People hate them because they are complex, configurable, and have 1000 features.
But that's the same reason they can sell into law firms and oil refineries and animation studios and all those other very diverse businesses.
And most enterprise software sucks because 1) writing complex, highly configurable software is hard and 2) very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable.
That the end user isn't the purchaser isn't going to change that fundamental reality that businesses are complicated.
No, this does completely get it right. Enterprises thought they needed all the control and security features of Blackberry until the iPhone came along and made the UX gap unsustainable. Enterprises thought they needed on-premise hosting of Exchange, Office and SharePoint instances under their control for email and productivity, until GSuite came up with a better, less configurable user experience based on consumer features that is making inroads in the market and generally works better for users. Slack is another proof point - the "consumerization of IT" trend in general.
There absolutely are outlier businesses like banking, government, healthcare and other highly regulated fields where they do have critical control needs. Notice how all of these are associated with crappier UX.
But the average business does not really have such needs, or at least it can be a mistake to blindly trade off employee happiness and productivity against feature checklists, yet that is typically the approach employed by procurement experts.
>No, this does completely get it right. Enterprises thought they needed all the control and security features of Blackberry until the iPhone came along and made the UX gap unsustainable.
The iPhone took almost a decade to get to the appropriate functionality. The part you're leaving out is most executives just ended up carrying two devices and whined to IT about "why can't YOU make my iphone as good at email as my blackberry???"
>Enterprises thought they needed on-premise hosting of Exchange, Office and SharePoint instances under their control for email and productivity, until GSuite came up with a better, less configurable user
Except I can count on one hand the number of fortune 500 enterprises that moved to gsuite over o365.
>Slack is another proof point - the "consumerization of IT" trend in general.
I'm not even sure how this is relevant. Companies that were using skype for business or cisco jabber likely still have skype/jabber running alongside Slack.
This reads like someone who lives in the valley and thinks the valley is in any way reflective of corporate America. Hint: It's not.
The iPhone took almost a decade to get to the appropriate functionality. The part you're leaving out is most executives just ended up carrying two devices and whined to IT about "why can't YOU make my iphone as good at email as my blackberry???"
That’s not true. The iPhone became good enough to replace the BlackBerry around 4 or 5 years in. By 2011, the BlackBerry was losing market share as Apple added enterprise features.
I, for example, enjoyed the wheel. Scroll wheel to email you want to read, press wheel to open, scroll to read. To be honest I don't remember how I close email, click wheel again or another button, but the whole experience can be done with one hand/thumb easily, while holding coffee in another hand. Try that with iPhone.
My issue with Swype-style - after having used it for about 8 years before switching to a phone with a keyboard (Android Blackberry) - is that having to wait for each word to confirm it got the right one is where the slowdown is. Touch-typing means I can keep going without confirming, because when I do mis-type, I can feel that my finger wasn't positioned correctly without having to do any visual confirmation.
Based on reactions from co-workers though, it seems I'm much more efficient at touch-typing than most of them, even on a fullsize keyboard. And the experience does translate to a physical phone keyboard, even at the smaller size, so that may well be where some of the disconnect is.
Note also when touch-typing on my phone, I get the full speed by using both thumbs, not just one.
Yep. Autocorrect's one of the first things I turn off on any device. I'd rather have a misspelled word than an entirely wrong word.
Case in point: people spelling "definitely" as (I assume) "definately" only to be autocorrected to "defiantly" without noticing. That sort of "correction" completely changes the meaning of a sentence.
This does not compute. I am a fast typer on all mediums, but a touch screen is just so slow compared to physical. I think I got around 80 wpm on my blackberry, there is no way I could do that on a touch screen. And iPhone autocorrect is terrible with any sort of tech jargon - frequently causing manual corrections.
I've found that haptic feedback helps. My first smartphone was a handmedown first-gen iPhone, so I didn't really understand the point of haptic feedback because I wasn't exposed to it, but upon switching to a Galaxy SII and feeling a tactile response with each press I've yet to look back.
Every time haptic feedback turns off for "power saving" when I'm running low on battery, I immediately wonder how anyone ever manages to type anything at all without mucking things up all the time.
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.
BlackBerry couldn’t read many attachments let alone edit them. Modern smart phones can run a decent version of MS Office.
The BlackBerry Email client definitely didn’t have a method of integrating third party storage providers like Dropbox which was definitely a thing by 2011.
Search. I could instantly search basically my entire inbox in 2005. That was the power of BES. I still can't do that today on Android or iOS. If I'm looking for an email from 6 months ago or last year it takes FOREVER to find.
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.
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.
So the first ones used pager networks, the next generation used cellular.
The push service was quite good IMHO. Every carrier that supported BlackBerry Internet Service had a leased line or VPN to the RIM NOCs. The phones would connect to BIS servers at the carrier which then communicated over these backhauls to RIM. Because it was all so deeply integrated in the carriers network (I believe the BIS servers acted as a Gateway GPRS Support Node), the BIS servers knew exactly where on the network each phone was, so they could send essentially a UDP packet directly to the device, which was listening on a particular port. No long standing TCP connections, and of course if the device didn't acknowledge messages, they were queued at RIM for when the device reentered coverage.
Email was provided by a server side process that opened MAPI (the original exchange RPC protocol) connections to exchange mailboxes and asked to be pinged if there were changes in mailboxes. When that happened, the BES server would pull the changes, package them, forward them to the RIM NOC over the proprietary SRP protocol, which would locate the right carrier, send the packet over the backhaul, and then from the carrier it would make its way to the phone.
This sounds worse than modern ActiveSync - which Apple introduces support for in 2010 (2009?). You also didn’t have to send all of your email through BlackBerry’s servers.
With ActiveSync, my email will usually reach my phone/cellular watch/iPad before it reaches my computer.
I mostly agree although I also think a lot of businesses think they are a lot snowflake-ier than they actually are.
But in my experience, smaller businesses can actually be worse offenders in this regard. Large enterprises actually do have a lot of complex needs and even relatively small changes affect a lot of people. But I've had someone at a very small company argue with me that they needed their own Exchange server because Gmail (at the time) didn't have some features like sub-labels/folders that they were used to.
> That's maybe another way of showing that UX is not the winning differentiator in enterprise that it is in consumer.
But it is. That and useful features. Both of which Office has, and GSuite has not.
I don't remember the name of that "Word lite" program that was included with Windows for free around Vista/7, which could open less sophisticated .doc files and was a default binding for .rtf files. But compared to Microsoft Office, GSuite is like that program, but on the web.
I have worked in enterprise for 20 years and have always been watching the vast majority of my colleagues (by the numbers) struggle to make anything but basic use of Office. My experience has been that there are a few advanced users who enjoy the mastery of it enough that they know it inside out, but the majority of enterprise workers really just do pretty basic stuff with it.
Meanwhile, the killer app of G Docs (collaboration) is a very frequently unanswered need. People emailing attachments with ridiculous names like "contract_v2_final_finalforreal.docx", making conflicting edits that cannot be reconciled, carrying USB sticks around because their PPT presentation is too big for email and they can never figure out how to use shared folders, etc.
Hey, I'm looking into a solution to this problem, I wondered if there was a way to DM you about your experience? I've been working on something and would love to hear thoughts around how people solve this where gDocs etc don't. Thanks
Word has a lot of features and, for certain publishing needs, these are important.
But what gsuite adds is usability. You no longer need shared drives. You no longer need to email docs around, you no longer need Spec_new_v3_new.doc.
I don't even need my computer any more, I can use anyone's.
I also don't need the immense amount of publishing and formatting options word provides. What I need to do is create documents that can be shared and collaborated on easily.
Enterprise software is a sub-class of business software. Enterprises often operate quite differently from SMBs. Public US companies will have things like SOX compliance. And, the enterprises offering up services, like email, may be competitors in another space. If you are competing with Google on phones do you want them to host your email? Likely not.
The business world is complex.
Some complex business software is fantastic. For example Excel. It's complex but you can do amazing things with data without learning to program (which is most people). You can use it while being on or off the Internet (this is great on a plane).
For UX many have given up security features. Many of us now have free credit monitoring because that lack of security has lead to leaks everywhere. I know people who have had their identity stolen and even attacks on retirement funds all due to companies lacking in security. Our drive for the new shiny has left many vulnerable.
> For UX many have given up security features. Many of us now have free credit monitoring because that lack of security has lead to leaks everywhere. I know people who have had their identity stolen and even attacks on retirement funds all due to companies lacking in security. Our drive for the new shiny has left many vulnerable.
I would lay money that far more security vulnerabilities are due to overcomplicated customizability features than are due to simplified UX.
I would argue it's more complicated than that. In my experience, especially I started working for some enterprises, the people who make the complex software are also the ones putting in the time and care into security. It's not a causation but there is something to be said about culture.
I wanted to do everything in Excel lately, but it (at least 2013 that I'm stuck with) seems to be a horrible frankensteinian mishmash of features that don't work together. For instance, there almost seems to be the infrastructure for building a virtual database in a spreadsheet, but there are a million different things that trip you up, like the not-quite-integration of PowerPivot, the use of DAX instead of SQL, the missing VBA interface for crucial things. I still don't know why you can use OData from Excel, but then you add something to the data model and try to get to it from PowerPivot, and you don't have permissions for the exact same URL and then the whole thing gets corrupted.
Within Office, it seems more practical to do ambitious things with Access, although that has its issues too. I apparently completely corrupted a database I've been using just by pasting part of a SQL statement that was >= 1024 characters as part of a VBA script.
Another big gotcha that hits large public organizations is that the software must be ADA compliant. This is extremely difficult and expensive to meet. Most small vendors do not meet the minimum requirements or even consider doing so.
Is this the same major EHR vendor that tells its customers to shut the system down and go to backups during the DST fallback hour?
There were many potential patient safety issues due to mishandling of times during that hour and the suggestion to just use the backup worked because it happens at 1 AM when little is going on other than emergencies which simply have to to manage with read-only access during that time.
No, but it is an interesting problem. If something is done every 4 hours at standard times, do you shift all standard times by an hour so it’s still every 4 hours or have a gap of 3 or 5 hours for that task.
I kinda like the idea of regular scheduled downtimes of stable systems, just for real experience on downtime procedures.
Interestingly it is rather straightforward to meet. It is very difficult to prove compliance. Most sites with web front ends should be ada/508 compliant, but documenting it is similar to other paperwork exercises (iso9000) that cost a lot but have little real impact.
As someone who is building a B2B SAAS company and made the decision to not focus on large-enterprise, I think you're both right.
At the end of the day, it's just plain hard to create a clean effective product that can be used by 5,000+ person organizations.
Regardless of use-case, boatloads of data will be collected in large-enterprise software and it has to be transferred and presented to many end-users in a clear way. And very rarely will it be one exclusive universal data-type. Usually it will contain varying types of information that will be needed by multiple teams and maybe across several different office locations. And that's just the product issues, let's not talk about sales or compliance.
This gets closer to the underlying truth. Even if you had smart procurement people who understood the benefits of great UX, another issue would be that enterprise problems are typically sub-scale compared with today's consumer products. There is one or two orders of magnitude more complexity and one or two orders of magnitude less users than in the consumer space, or even less for niche industry needs.
Even if you make it up with additional willingness to pay per user, the market isn't always there for spending a lot to design, develop and iterate on the perfect UX.
I think a lot of SaaS companies end up failing fast when they focus on the enterprise. The sales cycle is longer, and having a massive client can end up putting their individual needs over features that would make the product more attractive to the market as a whole.
SaaS makes the most money when users can self-service in large numbers at relatively low transaction costs, which typically means SMB should be your first market. The enterprise channel is where you go only once you have a mature product and a healthy revenue base to do the enterprise payola scheme with consulting companies.
In enterprise the incentives are all wrong - individuals who are decision makers for enterprise software/networking/security/etc have an incentive to make their job as complicated as possible so they can be promoted or build their empire through hiring new resource to keep on top of the complex web they've built
This is something I see all the time when a new developer comes on board with stars in their eyes. The first thing they try to do when they see a glaring inefficiency is fix it. Then they get burned at the stake because the inefficiency they are publicly denouncing is the reason a whole team of people exist. Large portions of every enterprise are essentially parasitic.
You're confusing "checklist-driven development" with developing needed features. I'm guessing because you assume that the features actually work. The problem of enterprise software is less that the features are unnecessary, and more that they work only on paper, but not in the real world. Since the software is sold to people who aren't using it, they can't evaluate the actual implementation and usability - so what gets sold is garbage that meets criteria.
Now what I see you arguing for is not "consumerization of IT", but infantilization of IT. Modern UX is oriented about dumbing down software, removing necessary features because they're "unused"[0], and about a myth that you can eliminate training time. Which is why people - again, not the users - buy into it. The sales strategy is: put it in the cloud, ask for subscription while screaming "it's OPEX and not CAPEX", and remove any and all features so everything looks slick on the demo, and the problem only becomes apparent when somebody tries to actually do something with it.
And then actual users have to suffer. For as much as software is eating the world, I wonder how much actual, hard productivity does the modern software of the web cost, compared to the software it displaced.
--
[0] - The way "data-driven" approach would tell you that there's no point adding airbags to cars, since almost nobody uses them ever.
> But the average business does not really have such needs, or at least it can be a mistake to blindly trade off employee happiness and productivity against feature checklists, yet that is typically the approach employed by procurement experts.
I think there's a different dynamic at play: the individual is making purchasing decisions based not on what they think the business needs but on what they personally want. E.g. JIRA has a huge number of micromanagement features that I doubt procurement departments are looking for; rather they appeal to managers in companies where they're the ones making purchasing decisions.
Related, my co-worker and I have evaluated a dozen different tools big and small, including Jira and that Jetbrains thing. And we still can't find a system that would meet our needs, which I think are simple:
- Model tasks as DAGs, not as lists. I.e. I want to work with a dependency graph (JetBrains thing sort of can do that with task relationships, but the UI isn't oriented towards exploiting it).
- If that's too much to ask, at least allow to nest arbitrary amount of subtasks, and not just one (like Jira and almost everyone else).
- Fast.
- Proper keyboard shortcuts (again, JetBrains is good at it, but it's missing some crucial shortcuts and UI concepts, like "add a subtask to current task" and "go back to parent task").
- Allow estimating how long the task will take, without having to specify when it'll start.
- Render a proper GAANT chart and do a critical path analysis.
I really think I'm not asking for much, and yet nothing I've seen can do it. Most Jira-like systems try hard to be "agile", which means sacrificing features and utility to chase misguided ideological purity (like the whole "no subtask" thing).
Seriously, if Emacs had a first-class support for real-time collaboration, Org Mode would be vastly better than all task management offerings on the market.
The compelling feature of gsuite for my employer was apparently the ability to turn off IMAP etc and therefore rule out emails being kept locally/beyond the retention period for better access control/cheaper legal compliance, not anything UX related.
You're thinking about this very much from a techy point of view.
We have a similar value prop with our platform (we store PII including actual identity documents).
It's not about making it impossible for users to download and store sensitive data. Everyone knows that that's impossible - yet somehow Snapchat and its disappearing messages is still a thing.
Instead, it is intended to be coupled with policies. As long as the company has a policy against downloading/storing confidential information, then the company is covered.
Then, when a case of e.g identity theft happens through a rogue employee, the company can demonstrate that it has taken all reasonable steps to avoid it.
That is a much better position than showing up in court and saying "yeah, we didn't try to prevent people from downloading PII, that's impossible anyway".
This is exactly right. It doesn't stop espionage or a rogue employee - it is not supposed to; but it does stop inadvertent duplication all over the place in ways the company could be liable for due to inaction or insufficient policy around PII, etc.
Not every employer hires folks like you who go out of their way to print confidential emails so they can violate customer privacy.
MANY employers have folks who unless you put a speed bump in their way would have employees inadvertently sync their entire email history onto their kids computer or a random computer while traveling.
The ENTIRE POINT of MANY of google's settings is to allow for those railings to be put in place. This is so employees who aren't out to abuse data can go about their day with reduced risk of inadvertently screwing up.
This is a big risk factor (I'd argue a much bigger risk factor than intentional employee misbehvior).
Additionally, once these controls are in place you can actually drive even better security where needed - it is possible to do a USB / printer / no phone lockout for high security ops - and is done when needed (very rarely). Thin clients are actually popular here - remote desktops another layer making it harder to dump the x million records out of system.
I don’t think it’s fair to jump to the conclusion that management at the GP’s see their employees as malicious. It’s far more plausible that they just don’t want emails automatically downloaded and stored on everyone’s computers.
Many companies have strict regulations on data retention and they’re regularly audited to ensure compliance. By keeping the data off employee computers, compliance is simplified.
It's worth noting that outlier in size or organization-count may not be outlier in money, and money talks when designing enterprise software.
There are a handful of banks, but they have all the money. The specialized features they care about speak very loudly at feature prioritization meetings.
> No, this does completely get it right. Enterprises thought they needed all the control and security features of Blackberry until the iPhone came along and made the UX gap unsustainable. Enterprises thought they needed on-premise hosting of Exchange, Office and SharePoint instances under their control for email and productivity, until GSuite came up with a better, less configurable user experience based on consumer features that is making inroads in the market and generally works better for users. Slack is another proof point - the "consumerization of IT" trend in general.
O365 far exceed Gsuites market share and is generally better for users because most companies users still use the Outlook desktop client.
MS Teams exceeds Slacks market share. Team instant communication is a minor blip in the overall market for Enterprise software.
> Notice how all of these are associated with crappier UX.
Having configuration that adopts to compliance and regulation is UX. The U in the UX is just not the end user but the admin user.
Consumerization of IT is absolutely a thing, but not for this is for productivity apps, not enterprise grade apps - you're conflating the two.
To pretend like all of the features demanded by enterprise middle and upper management is irrelevant and unthoughtful, as another comment said, is just "typical SV think". UX to the end user is certainly becoming much more relevant in the enterprise space, it's not as black and white as you think.
(note - i'm a former SAP employee and I've certainly seen my fair share of shit)
I think you and I are saying the same thing. I'm not saying Slack makes Msft irrelevant. Just that Slack makes better UX which is why they're managing to make sales outside of IT traditional channels - because once users have the power to do it, they choose something else than what IT gives them. Same with iPhone. It got so bad that in many companies, people started using them in breach of corporate preference for official systems.
Just today I met with someone who carries two laptops for work: one that is enterprise-IT sanctioned to access internal resources and is super restricted; the other one to do actual work. How does he work with two laptops? SDcards. In 2019.
The fact that all the craptastic enterprise UX is holding on so well in terms of the $ amount indeed is the observation: enterprise services for the most part do suck.
I don't think, and I didn't say, that it's always a winning commercial strategy to focus on UX when it comes to enterprise. Based on available evidence, I too would conclude that focusing on giving middle managers a power trip of control options looks like the better strategy, UX be damned.
This, in my experience, is what seems like the most likely culprit. A CTO/CIO gets impressed by a fancy feature list when really, what would be the best fit is something simple, stable, and easy to use. We have more and more examples nowadays of ease of use beating out giant monoliths and it's only likely to continue except in a few fringe use cases.
There’s supposedly an axiom for salesforce that it’s easier to be successful with salesforce if you adapt your business practices to match salesforce instead of the other way around.
> But the average business does not really have such needs
Well the average business is by definition not an enterprise. Enterprises need things like a solid AD integration, self hosting, enough monitoring coverage to put things like DLP and anti virus controls in place (yeah I know anti virus sucks, but work in a company with 10,000+ people, and you’ll see it getting genuine hits every day).
The fact is a lot of the modern software with good UX that we all love doesn’t meet these basic requirements, or at least doesn’t meet them as well as the old enterprise stuff does.
Many “enterprises” are their own worst enemy in terms of UX, by simply not valuing it enough. But I’ve worked in some that have made incredibly well organized, well resourced, and well supported attempts to modernize their technology stacks, and the truth is that the best and most innovative software that’s produced today, often (and perhaps rightly) doesn’t have the basic needs of enterprise in mind. So even with the best intentions, you often end up stuck using apps with poor UX.
As a side note, you can do absolutely fantastic DevOps in enterprise these days (even if you’re on a VMware stack). But a lot of the user facing stuff still sucks. Especially IM, which is why I have little hope that the enterprise love of email will die anytime soon.
> There absolutely are outlier businesses like banking, government, healthcare and other highly regulated fields where they do have critical control needs.
Control needs, yes, but there’s still a massive amount of trust required.
If the software could always prevent you from doing the « wrong » thing, then that task would be automated. Logging every action isn’t the complicated part.
But the bit about workflows is 100% true. No two hospital systems are the same. You can’t buy your Diagnostic Imaging equipment from the same vendor as your registration system, each with their own workflow.
You could probably fingerprint every hospital system based on which different clinical vendors they’ve adopted for their various functions.
But when the enterprise software authors want to capture 100% of the marketplace, they are, of course, writing their offering to support those few specific industries.
... which adds features to the product as a whole, which other customers will need to be aware of and might take advantage of.
Heck, even within my niche corner of the enterprise world (coincidentally a similar niche as Blackboard), there's always a noisy client who demands X. I can make all the good-faith arguments about why X really isn't needed, but if that client is threatening to go to a different vendor or sue, X is getting built. As a developer, there's only so much I can do before an account executive or C-suite tells me to quite bitching and just do it (and more often than not, they don't disagree with me in principle, but money makes the world go around).
Despite what it seems, demand for features is really NOT why enterprise software is (so often) bad. The problem is how easy it is to SELL fundamentally bad software simply because you can tick a box saying it has the feature.
Yes, I too have seen the phenomenon of having too many people demanding features where the result turns out to be an incoherent mess. But I also know that if the massive amount of time and money that had been spent purchasing a box-ticking Enterprise Software Solution and subsequently hammering the awkward, unwieldy platform into some semblance of working order had been spent instead on direct improvements to the existing workflow software, then everyone would have been much more satisfied. And yeah I know I shouldn't speak hypothetically but you'll just have to decide to trust me on this or not.
I think you're absolutely right. One error some organizations make is trying to buy a COTS product they assume will be simpler and more robust (and have its bugs fixed "for free" by the developer of the product) over hiring a part-time or full-time staffer to maintain and improve their existing non-COTS workflow (including owning all the bugs).
Sometimes (I have no global numbers to even guess at how often), they end up discovering that the COTS product requires expert-level configuration and administration anyway and now they're footing the bill for someone else's licensed solution and a staffer to understand it and make it work.
They aren't, though. If the big "Enterprise Software" players like Salesforce and SAP sell to healthcare providers it's either not with their flagship products, or else it's with incidental business processes not related to their core and peculiar requirements.
I don't think your comment is accurate, based on my first-hand knowledge of large companies that use gsuite, as well as their customer list in the above link.
They used gsuite for email, o365 for other aspects. Required iPhones if you wanted a device - wouldnt allow android at the time... but that may have changed since
This makes sense. Given my experience in tech startup land, im going to take a stab at how this happens from inside the company.
Lets say you are starting sn enterprise saas company, woohoo! You have your initial product and customers love it, yes! Things are starting to hum along nicely.
Now your sales people are identiying new markets and saying “hey if we add feature x and y, we can make $x million more per year from x y and z clients”.
At this critical juncture, managwment most likely approves and has UX involved, but adding the features will be the priority regardless. Theres no overrulin g UX voice that can say “no, dont build that feature because theres no way to maintain the delightful user experience” because MONEY IS ON THE TABLE! Execs got revenue goals to hit, sales people have revenue goals to hit, and this seems like a match made in heaven. Additionally, its important to point out that pioneering companies dont know all the end state user flows at the beginning so they are hacking along, reacting as they learn more about end customers.
Now fast forward a decade. The software is bloated but has grown a lot. Users hate it. New startups look at your product, your end customers, and say “hey! We can do this more simply and steal their customers”. And they can, because they have the advantage of starting from the ground up, KNOWING THE CUSTOMERS and their workflows. So of course they can build a more efficient product because they have the clear end vision - your product, but with the bloat cut out.
Your team has already done the hard work of identifying the best and largest customer use cases.
So what’s the solution? Acquire these upstarts or make your company a platform. I dont what blackboard has done here but salesforce is still by far the largest game in town despite universal hate. Why? In large part due to the vast network of 3rd party developers who can configure salesforce to a customer’s complicated workflows. They’ve actually taken this problem (it’s complicated to use) and turned it into a retention feature. No wonder they have a giant skyscraper in san francisco.
A lot of SaaS businesses aren’t really SaaS, they’re glorified custom development shops with a few high paying customers.
That’s not a great business to run though as it’s very difficult to scale.
Far too many fall into the trap of saying yes to the first BigCo that comes by early on because they need the $$. While they neglect every other niche and business where it could fit like a glove.
Or more often doesn’t even bother legitimately testing it on the open market since their very limited programming time is spent serving BigCo and doing support.
A lot of companies using SaaS have a bunch of different systems interconnected with Zapier or their own systems. Which IMO is far more like Unix than x product that turns into a full blown CRM, CMS, ERP etc tacked on top a niche product.
Building highly customized software also generates tons of risk for smaller companies as it binds their entire revenue on the success of a small group of other companies who may die, switch core business, or get stolen away by a bigger enterprise software sales team.
I’d much rather build a niche software product and instead of building a CRM on top just add every sort of API, webhook, Zapier, or direct integration. Or isolate them into separate products with shared authentication and logging systems.
> they’re glorified custom development shops with a few high paying customers
That's true, but sort of necessarily so, though. How else do you build a product that meets such a broad set of needs? Someone's got to do the work. At some point, features are going to drop linearly.
A lot of the time the client would be better off buying actual custom software. It's very easy to end up with a SAP (say) "configuration" so complex that you'll spend more on maintenance than you would if it were a standalone program.
> A lot of the time the client would be better off buying actual custom software.
I agree in theory, but I thoroughly disagree in practice.
If a client could spec/develop good software and cost it realistically, then sure. But I have rarely had clients like that - instead they think the problem-space is simple and end up with a half-baked solution that can't be maintained.
Developing greenfield software is a high risk strategy. (Edit: with a high reward if core function, and not much reward if not core).
The pretence that there's cost savings, followed by the sunk cost fallacy.
This happens because management is doing cover-your-ass methodology of software procurement. If they backed a greenfield development and it failed, then get blamed. But if they choose SAP/salesforce/bigCo, the same failure can be blamed on the vendor, or if it ran over budget, they can claim the vendor is expensive.
That's very true but still, in my experience anyways, it's much easier (i.e. perceived as 'less risky') to buy SAP and attempt to roll it out than to convince others that custom software would be better.
'Custom' is scary in a way that 'customizable' isn't.
It's hard not to wonder what might happen if more managers and executives became aware of "The Inner Platform Effect" and that "customizable" often just means "custom, but a worse, more expensive programming language".
Are SaaS businesses really customizing for high paying customers? They may build new features which are then made available to other businesses but I would be surprised if there are separate source trees.
The other issue is that a "great business" and "scale" are not synonymous. In fact many of the current batch of companies of great scale, like Slack, have spent enormous amounts of money to get there, and still lose money after becoming public. Then you have a company like Atlassian, with a confounding mix of enterprise products that are hard to use: but a fantastic businesses that's been profitable since the very beginning.
I do agree with you that the APIs, webhooks, and Zapier integrations solve the problem of customization, although I'd still say it's less customization and more a bevy of options.
> Are SaaS businesses really customizing for high paying customers? They may build new features which are then made available to other businesses but I would be surprised if there are separate source trees.
They are often using the same source tree and instance, but are enabling feature flags for certain customers. This often extends beyond code to data and caching. These don't get maintained and are a pain for support, as well as developers/operations. Over time they are almost as bad as a separate source tree.
This has been my experience too, but with a slight difference - the new feature is very often an ask from sales, who are trying to close either a big new sale, or a big renewal. The prospect/customer demands some obscure feature that like 1% of our users will use (at most), but they’re a big prospect/customer. Product/UX/dev push back, say we should be working on features, performance and reliability that will benefit most customers, but it’s hard to come up with the precise revenue impact of this. Sales are better at convincing execs, and “this will help us close a $1 mil/year deal” is very tangible, so the new feature gets built.
This is kind of a symptom of “the buyer isn’t the user”, though. Often we build these features, then monitor usage, and the customer that demanded it doesn’t even use it! Or we build it, and it doesn’t matter, we still don’t close the sale.
I think the core issue is “building for users” and “building to close specific sales” are often strongly at odds with one another, and most of the time “building to close specific sales” wins.
This makes sense to me. Sometimes it’s not even about more money but existence entirely. Seeing as that VisiCalc was _the Spreadsheet_ up until Lotus came along and ate their lunch, it’s easy to see that sometimes features and other external forces may have more of an impact than the raw popularity of a product in the end.
Exactly. They also control the workflow. If you don't like the 15 steps it takes to update your expense report, good for you, you won't get paid.
Companies will lose deals unless they do what customers want. Eventually, that chunks up the software and makes it awful. That's just the nature of the beast, and it's no different than things were pre-computer.
I had a .gov customer that had a very specific ruleset about stapling paper forms a certain way, which impacted how certain processes worked after they were computerized. Nobody understood why, then we found out -- in a tragic accident, a key employee in one of the paper processes in the 70s lost an arm. They ended up stapling things a certain way to accomodate his constraint and optimize throughput. The practice spread to other areas. 30-40 years later, after the employee was long retired and dead, the process lived on.
In the case of something like Word, people who write need to do stuff. I probably use 30% of Word features, but in the 2 times in the last decade that I needed to create a document with a table of figures, it's there.
Companies like Basecamp and Trello are here to prove that assertion wrong. Basecamp is in every fortune-500 company more than once and never officially. Why? Because you don't need IT to approve it first and it's price is just under what most managers can stick on their company credit card. One of Basecamp's mottos is "Do Less".
It's also worth pointing out that the simpler the software, the more likely it is to fit in with more companies' workflows. As soon as you start adding niche features the more likely it is that they won't fit neatly with most places they are sold into.
You actually do probably need your IT department to approve your use of Basecamp and Trello. It's very easy for project management and tracking tools to accommodate sensitive information like pending deals, new launches, or even PII. Your IT department probably isn't happy about rogue usage of external/third-party tools for storing data that they haven't properly tracked and can't wipeout or revoke if you quit.
Whether or not you choose to respect those needs, they very much still exist for all larger publicly traded companies.
A good rule of thumb is, if you think your <medium-to-large corporation> doesn't need Shadow IT, it means you're not already part of your company's Shadow IT circle.
I should say, those needs exist for all companies, it's just that the larger publicly traded ones have more to lose from e.g. a GDPR violation, data exfiltration/compromise or accidental leak of financially impactful data.
Totally agree, but it takes a really strong product manager to stand up to a sales person with $10K in revenue from an enterprise buyer "if we just add this one feature they want".
The fact that the enterprise buyer doesn't actually need the feature, or could do it easier/cheaper/better is immaterial. A Purchasing Department worker in the enterprise is looking at your product and Product X, and Product X has that feature that some manager somewhere in the purchasing process said they'd like to have. They really like your product, but they can't justify picking it over Product X without that feature.
Telling salesfolk that they have to walk away from the sale they spent months cultivating is hard, and there are often board-level ramifications to doing it. The entire company has to be behind "Keeping it Simple", including the directors and shareholders. This is why these companies (and products) are rare.
Product managers also need to stop living in idealized bubbles and actually understand their users and customers. What they want can at times can be dirty or ugly, and require PMs to challenge engineering stakeholders. There needs to be give and take there. Often PMs are getting crunched in the middle and don't have the wherewithal to deal with these situations.
Requirements also change over time and PMs can end up chasing a vision that doesn't exist. If PMs get out of their bubble and acknowledge this more they'd be trusted since there would be alignment on the long-term value for the customer and therefore sales. There are times that PMs need to show backbone when dealing with sales, or leadership, on features that might derail the product, but this doesn't have to be the default.
>Totally agree, but it takes a really strong product manager to stand up to a sales person with $10K in revenue from an enterprise buyer "if we just add this one feature they want".
Lol, let's be realistic. If a PM is in the situation to decide that and does so, in a few days he'll find himself in a meeting with some higher ups to discuss how to find a way. (Unless of course 10k is insignificant for the company and there's already a hard roadmap for higher value projects.)
I'd refine your examples somewhat. The author's idea of "enterprise software" would be more like SAP/Salesforce/JIRA. A client-server model type of software (data lives in big central corporate databases) instead of being documents-oriented (user data lives in files like .xlsx, .docx, .psd).
In contrast, the other desktop software of Photoshop/Word/Excel is often bought by consumers outside of enterprises because that's the software they prefer. (E.g. artists buy Photoshop instead of using GIMP.) And in the workplace, a lot of analysts like using MS Excel.
I had the same reaction. I was wondering, "Since when are Word, Excel, and Photoshop enterprise software?" I've been using these as consumer desktop software for decades.
That said, I do agree with GP that enterprise software is complex because it's designed to be adaptable to existing processes, whereas simpler software seeks to adapt the user to its prescribed process. And even without being an enterprise, I often find myself drawn to software that adapts to my needs and preferences rather than the other way around.
Just because the advent of mobile-focused product sensibility has seen a (regrettable, in my opinion) general drift toward significantly reduced feature sets in software does not mean that existing software with broad feature sets is now "enterprise."
Anecdotally, 20 years ago, scores of programs allowed the user to easily and broadly customize the colors of their user interface. That sort of flexibility was among the first features on the mobile simplification chopping block. As a result, most software created within the past few years has a single "true and good" color scheme dictated by the designer. Today we see that evolving slightly with the popularity of "dark" schemes, giving the user a choice between two, but only two, designer-crafted themes.
> Since when are Word, Excel [...] enterprise software?
Since Word 1.0.
Why do you think it is called Microsoft Office? The 1989 edition of Microsoft Word cost $500, equivalent to over $1,000 today, for a single seat. That's not consumer software.
Microsoft Home didn't exist until 1993, a decade into Office's life, when it had achieved complete enterprise dominance -- thanks largely to its competitors' failure to release Windows version in a timely fashion in the late 1980s & early 1990s -- and Microsoft began pushing into consumer software.
Microsoft didn't use the "Office" branding until 1995. Before that, the computer industry called it "productivity software" instead of "enterprise software". In the 1990s, other software companies (like Borland and IBM) were bundling word processors + spreadsheets + presentations + databases into an "office suite" for a lower package price.
In the 1980s, Microsoft Word was competing with WordStar and WordPerfect and those were all consumer software for personal computers. Consumers could go into an office supply store and buy shrinkwrapped boxes of those software titles. They didn't need a purchase order from corporate accounting to buy an "enterprise volume license". And consumer magazines like PC Magazine and PC World would run articles comparing MS Word to WordPerfect, etc.
Yes, a Fortune 500 corporation today can buy a enterprise volume licenses of MS Office (or Office 365 cloud subscription) but MS Word's roots definitely included the consumer sector. I don't think the example of MS Word fits the author's idea of "enterprise" software.
There was also Microsoft Works, which was Microsoft's first integrated word processor, spreadsheet, and database. That was the low-cost consumer-level package for quite a while. It was often OEM-bundled, in hopes of eventually inducing users to buy into Office proper. Works was sold as late as 2007 before being retired in favor of Office instead.
When people say "Enterprise Software" they are not talking about shrink-wrap single-user office productivity applications like word processors and spreadsheets.
Maybe there should be another term to help clarify for people who don't understand the difference, but the difference really should be obvious from context.
I would say that its because people understand how to use it.
Excel is frequently used as a database, not because it makes a good database but because people don't understand how to use Access (or any other relational database) but Excel is easy enough that they can get something usable.
That's part of it, but not all and also not the most important IMHO
Excel clones simply don't cover the breadth of functionality provided by the OG, not to mention key UX features like countless hotkeys and menu accelerators
Every Excel user understands Google Sheets. They just don't like feeling like they're strapped to a wheelchair
Often they understand Access, they just don't have it.
Office Standard and Home & Business SKUs are without it, you need Office Professional Plus. Because it costs few hundred more for just Access and Skype, most workers will get the Standard one.
You actually need to understand the basics of relational databases in order to use Access effectively (unless you are only using a single table - in which case you might as well use excel).
Many people don't need complex features of Excel, LibreOffice is pretty good. Many people have Excel and don't even get to basic functions like vlookup, nevermind anything that is actually lacking from other applications.
But there are enterprise versions of Word, Excel, and a few others. And it's worth taking a look at what those versions add. By and large, being able to centrally manage and update from the IT department, and even being able to deploy additional content (plug-ins, templates, etc).
So, they're not client-server, but they do add a server into the mix.
The other common set of features is related to distribution and access. Encryption, workflow management, integration into server-hosted software, etc.
At a certain point, I think that enterprise software development starts to look like enterprise IT consulting. The line between then is pretty blurry, and I think that the really successful enterprise software shops are the ones that don't have an allergic reaction to doing consultant-y things as part of the product/services they offer.
Regardless, the purpose and core features of Word and Excel have not changed in 20+ years. MS Word is a Word Processor. Its purpose is to input and format text. Excel is a spreadsheet. It's purpose is to be an interactive way to organize data in tables.
Mentioning them as an example of "Enterprise Software" without specifically clarifying the Enterprise-features you're talking about is a mistake at best and disingenuous at worst.
I've worked in enterprise software for 15+ years. Enterprises don't have complex and unique workflows, they generally have lazy and shitty workflows because people don't care.
The reason why enterprise software sucks is many-fold. My top reasons are the following:
1) Enterprise customers spend a lot of money and thus demand a lot from its suppliers. Sales and PMs and VPs will do whatever it takes to make their numbers and make their bonuses, so they will sacrifice software architecture for customer happiness. I'm not saying this is wrong, but it's the reality.
2) Software shouldn't exist for 20 years. Imagine writing a book where the authors change every 2-3 years, and the incentive was to write the best chapter and then leave afterwards. By the end of the book, it's probably going to be a shitty book.
The only pieces of software where it works are things like operating systems like Linux where you have someone like Linus who really does care and has been around since the beginning. Even Microsoft fell into this trap, look at Windows Vista which was a disaster.
I don't buy it. I've worked at a Fortune-100 company with "complex and unique workflows", and we used plenty of customized enterprise software, and they were the worst systems you ever saw -- both before and after our customizations were implemented. The best ones were those where we completely replaced the native UI, and the only reason we weren't running our software against a plain database is legacy momentum.
You're either so big you're essentially doing custom development (or should be), or you're small enough you can't afford that and use whatever you're given with minimal tweaks to the UI.
I believe it's possible to make software that's both good, and flexible enough to stay good while avoiding complete custom development, but it's incredibly rare, because the 'users' in that case (i.e., local developers) are twice removed from the sales process.
"We have complex and unique workflows and need to customize the software to our needs" is simply another excuse used by executives to buy crap that users will hate.
It's true that enterprises have complex and unique workflows, and that this drives the complexity of enterprise software. What I doubt is that this complexity is actually adding value in most cases.
There is a nice equilibrium where companies adopt simple best practice workflows for non-core competencies, and vendors compete on how effectively they can implement those simple workflows.
In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility.
Thing is, enterprises have multiple incompatible workflows but still need to make it work. I.e. due to mergers and acquisitions different parts of the company have 3 different, incompatible IT workflows for part procurement.
Of course that's bad and a single system is highly desired - so the company is working on it, and within a year these three workflows are going to be combined in a single system. Naturally, that system isn't simple as it needs to combine the peculiarities of these three workflows.
Of course that's bad, and a single simpler workflow is highly desired - so the company is working on it, and within 2-3 years the processes are going to be adjusted and unified so that there's a reasonable single process.
However, there's another acquisition that's going to be finalized soon, and during these 2-3 years at least one more is going to happen, so by the time these workflows are unified and simplified, they will be joined by new parts of the company using different workflows, and the enterprise will be back to square one with 3 separate systems with incompatible workflows for doing the same thing.
Oh, I'm aware. I work in enterprise software. I see what the customers want.
I've also been on the receiving end: my company has one tool that doesn't work well. So for three years, there's been a push to get rid of it, but there's never been agreement on any replacement.
There's one particular use case that stakeholders think isn't handled by the replacements. The result is that we use both tools, and manually synchronize them. Someone wrote a bespoke automated tool to bridge those two SaaS apps, but it doesn't remove the manual synchronization, just reduces it.
Oh, these tools? They aren't for something low touch. People are in both tools constantly. There are questions about which pieces of information are accurate, and who's responsible for which updates. The time waste is significant.
But the problem isn't the software. The problem is that people can't make a decision. When you ask someone higher up, you get vague assurances that we're still thinking about the issue. In the case of the companies with their mergers, having one tool support both systems isn't doing anyone any favors. It just lets them limp along with excess complexity.
> In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility.
Enterprises are setup to support all of these baroque workflows and that's where most of the value is derived. However users and the business don't get that value, and the project to replace the previous one will deliver "value" to IT stakeholders. The cycle repeats.
You have enterprise architects who in the worst case are creating uncertainty by supporting different factions and introducing new tools which interest them versus meeting goals for the company. IT outsourcing vendors are responsible for the implementation and frequently do a less than stellar job. Security are split between trying to keep tabs on how the outsourcer is running things, while trying to limit how much damage business areas do by just delivering their own solution with SaaS or a small vendor. This is a real mess that requires huge amounts of energy, and is hard to fix because everyone is doing pretty well from it in their own way.
> If you look at all of the most successful software of all time they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel, SAP, Photoshop, Salesforce, JIRA.
Setting aside for the moment the fact that Unix itself is also incredibly successful (both in a commercial and mindshare perspective) the items in that list are not necessarily commensurate.
Yes, they all have lots of features, but Excel and Photoshop were definitely built for their users, whereas SAP was not so much. As a consequence, Excel and Photoshop have very enthusiastic user communities, and SAP (et. al) users gripe a lot.
My thesis is that Excel and Photoshop were built around empowering the workflows of individual users. As such, it becomes possible to market directly to the users, even if someone else ends up writing the check.
Products like JIRA, Salesforce, and SAP are intended to optimize the flow of an organization. There's no single user you sell the software to that will benefit from using the software independent of what other people are using.
Also, the Unix philosophy isn't about limited functionality - it's about achieving rich functionality by having orthogonal bits of functionality that can be composed together in new and unexpected ways that can be reasoned about.
Programs/applications within Unix may be simple and single purpose, but Unix itself is not. Likewise, we may look at Excel as an application and deem it to be overly complex. However, as a platform Excel is fantastic in that it has lots of independent pieces of functionality that can be easily combined together.
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining.
This is the nominal reason executives responsible for inflicting terrible software on their workers tell themselves. But it's not always true. In fact it may often not be true. In many cases the assumptions about how much training is necessary to use the software are all wrong in the first place and the only reason so much training is required is because they chose such terrible software in the first place.
> People hate them because they are complex, configurable, and have 1000 features.
No, in fact it's often that they LACK features and are NOT properly configurable, because they are simply bad software from the very core. You often have a rigid and unwieldy platform with features inelegantly bolted on by underpaid programmers to satisfy corporate buzzword checklists. The end-user experience is furthermore left for last. So not only are you trying to design a UI on a garbage platform, it's your lowest priority. So worker efficiency takes a hit, a hit that you can't measure so you just dismiss and issue beatings to anyone who doesn't use your awfully-designed software effectively.
For a real-life example:
Good Trouble Ticketing Software designed around trying to help teams track work and be more efficient: Request Tracker from Best Practical.
Bad Trouble Ticketing Software nominally designed around being "ITIL compliant" and providing nice reports to management, but is actually just really large badly designed CRUD: Service Now.
I think this gets it fundamentally correct, although your point has some validity. But the reason that enterprises often wish to pay for configuration of the software instead of changing their own workflows, is that one of these requires no work from them (the decision makers), and the other does.
Much of what is called "enterprise software" is actually more like a proprietary programming language or framework, which you will have to pay specialists to program your application in, with bad debugging tools.
Lastly, Oracle and SAP and etc. aren't actually good at the problem you describe, as attested to by the many users who hate their products. They're just good at selling their software to the decision makers (not the users).
People love excel and Photoshop. I’ve never met any heavy excel user that prefers any other spreadsheet software or even has anything negative to say about it.
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 other type is the small business owner who is pretty good at spreadsheets but whose business is outpacing his spreadsheets' ability to keep up.
On three separate occasions I've had this sort try to hire me to help find ways to make their workflow scalable, perhaps by helping them write a little custom software. The problem is usually that the time for finding an alternate method was years ago. The spreadsheets these people come up with are amazing, it's like they've tricked out their tricycle so much over the years that it can now fly, just not well.
They always want to pay for my spare time, but the complexity is always such that they need somebody full time.
> would now be making significantly more money if they didn't
Er, I think reality is closer to "they would be making significantly more money if they loved python more than Excel".
A wheelchair is a large clunky device that can't go up stairs or rocky hills. Legs are far more versatile. But it is incorrect to say that someone can go many more places if they didn't have the wheelchair.
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 or accountants...
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.
Don't forget, the spreadsheet jockey not only shoots himself in the foot, he can also saddle his whole team with a dependency on his undocumented, un-version-controlled spaghetti macros, which will become a maintenance nightmare for years and years!
Yes, Excel really is a good product. But there are a few things people do consistently complain about with it in my experience:
- lack of forwards compatibility. When someone sends you an Excel 2016 file and you’re stuck on Excel 2013 because your corporate hasn’t upgraded yet, it’s a total PITA.
- weird bugs. Sometimes spreadsheets can get corrupted in weird ways so that they crash Excel and there’s nothing you can do about it and no way to fix it. Sometimes these bugs only appear on certain versions of Excel
- lack of decent built in formula tracing (ie something which brings up a dialogue and you can click through each reference in a formula browsing back and forth and going up and down the dependency tree). There are a few third party add one that do this but it really should be built in.
- lack of a decent way to see what’s changed between two versions of a spreadsheet
I’d also say there’s an inordinate amount of abusing Excel to do database tasks out there. People have spreadsheets which take minutes to recalculate which could be done in less than a second even using Access, let alone a ‘proper’ DB.
The great thing about Excel is that it is easy and intuitive to use just the basics, and it is difficult to accidentally stumble onto its advanced and complicated features by accident.
With Word, on the other hand, it is easy to have created a large document and then just as easily screw the whole thing up from beginning to end by clicking the wrong button or key-combination.
Yeah that was a very bizarre grouping of software. I’ve never before heard Photoshop or Excel referred to as enterprise.
There is a lot of bad enterprise software out there, Salesforce, Oracle, and SAP are basically catalogs of it. The fundamental problem as I’ve seen it relates to contracts and integration. Good software, the user can bail at any time.
There is a very simple set of red flags: the company doesn’t list a price, you have to talk to a sales person, and you have to sign a long term contract. I’m not aware of any software that fits those three that is enjoyed by its users.
Regarding Excel, its Mac version is terrible. Our heavy users have to run the Windows version in a dedicated Parallels VM to get anything done once the sheet contains more than a few hundred rows.
i used to be a heavy excel user, when i worked on windows, it was great for eyeballing data quickly, now, in a different job, i use a mac, i would really do anything i can to avoid using excel - visidata FTW http://visidata.org/ . I really don't miss excel at all
I was a workshop at the google office in Toronto a while back, and people asked when Google sheets would be able to perform big data analysis.
The presenter looked confused, and then the group asking the question clarified that their big data workflow involves loading millions and millions of records into excel and they would have trouble migrating to google cloud until google sheets could match excel in performance.
Somewhat unrelated story, but it shows how well loved some software is, and how some users will take it to use cases you never imagined.
> big data workflow involves loading millions and millions of records
Dude, if it fits on your laptop disk, it's not big data. Here you're talking about “big data” that fits in RAM on my cellphone. Somebody needs to get over himself.
But if Google Sheets can't fit the data they are using, it is by definition "big data", even if it's not Big Data. I think this over-protectiveness of the definition doesn't really serve anyone.
It serves everyone to have relatively stable meanings for words and phrases. "Relatively" because of course there is natural drift over time. But if today I write "big data" and it means "millions of rows in Excel" to Bob but "hundreds or thousands of terrabytes" to Jane, it's effectively useless to use in communication.
Put another way, that Bob thinks he's dealing with "big data" doesn't mean he is in fact.
In four lines you manage to be arrogant, insulting, patronizing, and intellectually sloppy (“by definition”?) I'm disappointed. I'd like to invite you to produce a higher level of discourse.
...you can't be serious. This is an incredibly over the top reaction to a very mild reply. Not to mention that telling me you're disappointed in me and inviting me to "produce a higher level of discourse" is far more arrogant and patronising than anything in my original statement.
But anyway, this is very obviously off-topic. I don't think it serves the wider community to continue this conversation so I'll leave it here.
That's really strange... I always found Excel to perform dreadfully on data sets with even just hundreds of thousands of rows - it was always easier to just load the data into a database, or manipulate it with a script.
That's because you don't know how to use Excel (this isn't a knock on you, no one ever tells people how to use Excel). Excel sheets have a hard row limit of around a million rows, but long before you approach that you will have moved your data into the "Data Model", which is a relational table engine stapled on to Excel, or to some other backend which you will query from Excel (often via the Data Model).
Larger issue is that Excel formula language has different separator characters depending on the locale. This would not be that bad if this would be case only for presentation in UI (.xls contains parse tree and .xlsx AFAIK always contains en_US syntax), but this difference is even in the format of CSV files processed by excel (there is significant portion of the world, where the C in CSV stands for semiColon, as far as excel is concerned)
Yes, same in Italian, and I guess in every other language.
It's dreadful but probably once you memorized all your favourite functions is quick to use. It's definitely not a tool for developers.
People have asked for this or the Spanish version of Angular or Russian Java. If I only spoke those languages I might want that as well. Surprised no one has tried to introduce this into popular programming languages.
The times when this was decided are remote in terms of computing. We're probably talking about mid-eighties. Excel is an office tool, and probably most of its users work in offices where not a single word of English is spoken, ever. So I don't think it was "asked by the users" but rather what's expected from a basic office tool, to be localised in your language.
Well there isn’t any better spreadsheet software in 2019. Like what even comes close in terms of features and fit?
Photoshop. I think it’s a tiny little more mixed opinion of the overall program in terms of UX, but again, the closest replacement might be Affinity. And that is too new.
I really would say your just restating the OP conclusion from the point of the of the purchaser instead of from the point of view of the software developer.
An executive at an Enterprise would state their search for some piece of software as: I have such and such problem. I wish someone would make a magic wand and fix it for me(how hard can it be anyway).
To which some software developer will reply. Hey we make magic wands. We make incredible magic wands. Let's schedule some time to show them to you. And the fact that the people who have to use it are not involved makes a huge difference in quality.
You give Word, Excel and Jira as examples of Enterprise Software. If these are examples of Enterprise Software they are by far the best examples of such Software.
Enterprise Software that currently makes my life miserable on a daily basis would be products like Remedy for workflows and approvals, Serena and Harvest for Change Management, WebSphere Middleware, CyberArk for secrets management, and WebMethods for an Enterprise Service Bus.
All of these have horrible documentation, are extremely expensive, and most have superior open source equivalents.
The only reason that companies like this can still stay in business is because there are executives who still believe in magic wands and then believe sales people when they say they have them for sale.
The thing is ... very few companies do actually use all the complex configuration of said purchased software.
Rather, they are stuck with it. And deal with it, limiting the contact surface, until they cannot bear it anymore, and spend more to upgrade/get some consulting to have the solution reorganized for them.
On one hand, you have purchase departments that are not the target users, and decide only based on paper reports, what to purchase. Losing the run from the start line. That's a given.
On the other hand, you have those who prefer to outsource the understanding of their own workflow/tooling/business, that could leave them somehow unique and different, to some outside flexible product that claims to solve that (and that meets this and this requirement from that body & that set of laws), but still requires armies of consultants to make it work properly, although it does not cover really your use case, so you better adapt your way of work to what "they" say is good (got Agile anyone?).
Why? Because regulations. Because market/business standards. Financial due diligences.
And why would they not prefer that? They (anyone, we) do not care. We are not paid to care for that. Or rather, we get rapidly burnt for caring.
That's like the entropy law for software & processes in enterprise in general.
Oracle, for instance (but that's valid for so many, if not all, enterprise-targeted solutions), didn't sell itself based on technical merits, you know.
Business are complicated, yes. And they get even more complicated because of people lacking of the courage to say fuck you to the salesman.
> The thing is ... very few companies do actually use all the complex configuration of said purchased software.
That's the point, though. Enterprise software is a superset (E) of all features that a large group of very diverse customers need.
An individual customer has a need for a much smaller set of features (C). That enterprise software may very well be the best software that includes all those needed features:
C ⊆ E
There are niche providers, so a logical customer would select the software that meets all of their needs and as little else as possible. But there may not be a niche provider that meets that criteria. So as an individual customer, you may be stuck between an Enterprise software that meets all your needs, but is "more than you need" and a niche software that doesn't meet all your needs.
> That enterprise software may very well be the best software that includes all those needed features.
How come you can't have something nice & even decently working for: pay, HR, vacation, expenses tracking?
Or more, how is it possible that obviously unfit and malfunctioning solutions (for problems that have been known, solved and specified for years) are still on the market in 2019 in companies that pretend to be serious about software?
Pay, HR, and expense tracking are extremely complex areas due to federal / state / local labor laws, collective bargaining agreements, and individual organizational policies. Any application which deals with all those complexities will inevitably be full of defects and usability problems. There is no solution, it's simply reality.
Do the users of the software need to know about all that complexity?
If the answer is: "they definitely do", then you are right. There's no way around it.
If the answer is: "No, they only need to know about 4% of it. The rest can be automated and hidden away." then the problem is that people aren't incentivised to pay the cost of building that software.
There is a broad solution:
Hire engineers, UX designers, and product managers to spend time to solve those problems and to manage that complexity. The problem is that this requires the time and effort of skilled people and that requires a sustained commitment of money. So that requires someone with decision-making power to allocate money from a budget of limited resources.
If the additional UI improvement helps win sufficient revenue, then its worth it. But if the additional UI improvement doesn't persuade decision-makers or only helps 1 client account, then it is not.
In this area of enterprise software, the users absolutely need to know about the complexity for compliance reasons. Any errors can potentially result in criminal charges, civil liability, or at least bad PR and employee morale.
Payroll might seem simple but in reality it's full of complex edge cases. For example, employers sometimes receive court orders requiring them to periodically seize a certain amount from a particular employee's pay in order to satisfy a legal judgment. And in some cases there can actually be multiple such orders that would effectively reduce the employee's take home pay below zero. Now what do you do? Please explain how engineers, UX designers, and product managers can "manage" such complexity.
> Payroll might seem simple but in reality it's full of complex edge cases.
oh I would definitely have assumed so. My question is to what degree does the UI need to lay all that complexity right out for the user and to what degree can it hide it?
If humans inherently need to learn about all that complexity, then the best you can do is make it not-needlessly complicated.
> Please explain how engineers, UX designers, and product managers can "manage" such complexity.
I can't do so in the space of this text box. The answer is practically the field of software engineering.
-------
I'm curious what your thoughts are on https://docs.gusto.com/ Is it another "yea, this covers 95% of my use cases, but I need that last 5%" Or is it good?
The problem here is putting the cart before the horse and expecting the software to implement policies for you. If you can't design a workflow to work and be compliant without new software, you probably do not know enough about your own workflow to purchase software that will actually improve it.
While enterprises businesses may not use every single feature, they typically end up using 90-95%. The problem is that the same tool is l used across multiple departments. Take Epic. The EMR is used by doctors, nurses, billing, operations, finance, executives, pharmacists. And keep in mind that the way doctors use it will carry depending on the department. That's a lot of use cases to support
Nobody hates Photoshop. In fact it's one of the most loved software out there.
I'm a developer and a Photoshop user and love it. The Unix philosophy would be a disaster for a image editing software (ImageMagick much?)
Once a developer who spent all day in VIM & co was honestly arguing with me that Photoshop should be a command line app. I filled that under "shit developers say" and "delusional".
It's a jumbled mess of features added over the years with no coherent UI workflow between them. It hides way too much of the complexity of image editing in one-click-effect solutions, that often don't compose well.
I don't know of any good competitors in its price range though. I would recommend Nuke if it wasn't that expensive.
ImageMagick is great, I use it all the time. Photoshop is superb for interactive image editing, but if you need to crop a thousand images, change brightness, add some text on top, and merge them one next to the other, for example, and you need to do this every day, a sciptable tool is essential, and I really appreciate having all the power of Unix instead of a limited environment that requires a huge platform.
Wouldn't it be nice to have a programming-by-demonstration system that lets you interactively develop a filter on one image, then apply it to many images?
I imagine photoshop has had it for a long time. I do raw photography very sparingly and barely know photoshop. Literally one of the first thing I wanted to do was batch operations on a set of photos in which the lighting and camera setting were exactly the same. A quick Google revealed it is frequently used.
And, FBOW Linux has the Gimp, which I prefer to Photoshop, though that's largely on account of familiarity.
ImageMagick itself is invaluable when what you need to do is programmatically change large numbers of images. I've seen it used on large (multi-million user) image-heavy sites as the standard image handling flow (thumbnails and default previews of standard sizes).
It's strange that someone who spends all day in Vim (which is not an acronym, by the way), an editor driven by keystrokes rather than the command line like ex or edlin, would prefer a command-line Photoshop. I'm not saying you're lying but maybe they misspoke or you misremembered.
A keystroke-driven Photoshop might be something like Blender.
I think netpbm is more Unixy than ImageMagick. I've had good experiences with it, especially for images bigger than my RAM, but a paint program it is not.
> I'm not saying you're lying but maybe they misspoke or you misremembered.
No, that dev never did any serious image editing. He was just full of himself and of the "superior UNIX philosophy", the thought that there might be domains where that doesn't apply just never crossed his mind (image/audio/video editing being a major one)
Vim does not use the Unix philosophy. It is an Amiga program ported to Unix, designed along the lines of Emacs, which also does not use the Unix philosophy. You would think he would have noticed that his text editor was a domain where he wasn't applying the superior Unix philosophy.
I'm not convinced that the Unix philosophy doesn't apply to image and video editing, but certainly we haven't seen an example (aside from filters, which work well in things like netpbm and Khoros, but I mean for actual interactive drawing and editing.) And certainly the performance cost of the Unix approach was infeasible in 1988, when Thomas Knoll wrote Photoshop. Still, the tree-structured pipeline structure of CAD models in FreeCAD, SolidWorks, and CATIA suggests that it might be a productive approach with enough work.
We have seen the Vim philosophy applied to video editing, with great success; that's Blender.
I was talking more about the GUI/command line divide.
SolidWorks/Blender are fundamentally GUI apps, even if they do contain some programmatic features (like parametric filters/models/...). Also, all media software have something like "Unix tools who do one thing well" - plugins, filters, ..., but you compose them using the GUI.
It sounds like you're being confused by the surface appearance of things, rather than paying attention to their fundamental nature. Maybe that's why you weren't able to understand the arrogant Vim guy's utterance and wrote him off as delusional instead of figuring out in what sense he might be saying something true. It's good that you did figure it out eventually even if you couldn't hear it from him.
Unix wasn't distinguished from other contemporary systems by not using a GUI. With a few visionary exceptions like NLS/Augment, SKETCHPAD, Spacewar!, and GENESYS, computers didn't have GUIs when Unix was born. The Unix philosophy wasn't about using textual commands. Every computer used textual commands except desk calculators. It was about a uniform interface that permits unrestricted composition of orthogonal software components, easy and expressive automation of routine tasks, and prioritizing usability over absolute computational efficiency. These are not, to put it mildly, Photoshop’s strong points.
I understand your point about Vim not following Unix philosophy, also the way Vim and Blender are similar.
I disagree that the GUI/command line divide is a "surface appearance". I'm not talking about Vim/VS Code kind of thing, where one is implemented in the command line, the other in the GUI, but are basically the same. I'm talking about apps which fundamentally require a pointing device. In Photoshop you point at a pixel and say "do something here", in command line ImageMagick you say "x=100 y=200". This is not a trivial difference to me, it changes everything and generates different usage scenarios.
Vim is not a command-line program. It's a screen editor. The command-line equivalents are Perl, ex, and sed.
I agree that writing +100+200x17x25 is a terrible UI design for drawing. But you’ll notice that Vim doesn't use such an interaction design for text; and typing the 100 and 200 into the properties box of a Quartz Composer processing node doesn't make it any better. So it sounds like you're attacking a straw man, maybe unintentionally.
I'm not sure what I'm attacking, certainly not Vim.
I'm just saying that you can perfectly use Vim without a mouse, in fact most guides recommend you to disable mouse (and cursor) support.
But you can't use Photoshop or Blender without a mouse. Sure, you technically can, in a limited way, you can for example crop images or apply global filters in PS with just the keyboard, the same in Blender, but certain core manipulations are impossible in both without a mouse.
I would argue that it's because of the much higher resolution of images/3d data. 80x50 with a 100 character alphabet versus 2000x2000 with a 16.7 mil alphabet. In Vim you say "move the cursor after 'func'". How would that work in Photoshop? "move the cursor after RGB(25, 15, 9) RGB(98, 126, 22)?" You can't even see the pixels in PS, let alone guess their values.
There are pixel art editors which are completely usable with just the keyboard, but they are used for images smaller than 256x256.
The best way to use Photoshop without a mouse is to use a Wacom tablet. My Fitts parameter estimates for mouse interaction are terrible, but much better than any keystroke interface I've seen, much less command-line interfaces.
You were attacking interactive image editing by typing strings of text:
> in command line ImageMagick you say "x=100 y=200". This is not a trivial difference
But I don't think anyone really thinks that's a good idea.
I agree that direct manipulation is a great benefit, and I don't think there is any plausible alternative for designating positions and especially paths in pixel images the way incremental search provides a better alternative for designating positions in text. Vim in particular is distinguished from vi by supporting more direct-manipulation and noun-verb interaction flows, and vi differed from command-line editors similarly by supporting more immediate feedback and pseudo-direct-manipulation interaction: you would change a word by typing fscwbad ^[ rather than s/strange/bad/^M, for example. I think this is an improvement.
I'm continuously kind of appalled that we're carrying around these high-bandwidth multitouch devices all day and apparently the best way we've figured out to take advantage of this situation is one-finger scrolling of lists of pre-existing options, tap-selecting, and a simulated onscreen keyboard, plus the occasional pinch-zoom. I feel like even pictures under glass is about 10 years overdue for some new UI paradigms to take advantage of the new possibilities of the medium.
I wonder if there's a way to describe and interactively refine descriptions of areas of interest in a symbolic way—as Lisp trees if not Unix strings—maybe using existing neural networks. Certainly a speculative idea, of course.
> I wonder if there's a way to describe and interactively refine descriptions of areas of interest in a symbolic way—as Lisp trees if not Unix strings—maybe using existing neural networks. Certainly a speculative idea, of course.
I think the future is more like saying to the computer what you actually want. Like "delete the apple from the picture".
Photoshop already has a primitive form of this particular action, called Content Aware Fill, where you draw a rough selection around an object you want to delete, and it will fill a plausible background in its place. Works pretty well.
In a sense these are different uses of a computer for graphics: one is a medium of human visual expression, which is Photoshop’s forte, while “delete the apple” is more like delegating a functional task to an independent contractor. I don't think one is likely to entirely replace the other, just as Photoshop hasn't replaced netpbm, photography hasn't replaced painting (even if we do more painting in PS than with paint nowadays), and the city bus hasn't replaced dancing or skateboarding, even though all of them are ways to move your body.
There are certainly some uses of PS that things like caption-to-image GANs will replace. Analogously, last night I spent quite a while with the expressive, high-bandwidth, direct-manipulation interface of a box cutter cutting cardboard, for something I'd much rather be doing with a laser cutter cutting shapes generated from a constrained-optimization algorithm. At least this time I managed to only cut the cardboard.
Texture synthesis is a really interesting tool for both purposes. There are a lot of amazing papers in recent SIGGRAPHs with new algorithms for this kind of thing.
EMACS was the extensible, customizable, self-documenting display editor, that did hairy things like turn your compiler error messages into hypertext and syntax-highlight your code—a massive amount of functionality tied up in a single garbage-collected process with an embedded scripting language, with potentially hundreds of files open at once. It came from ITS and Multics, where it provided not only an IDE but windows, on text terminals. It inhabited Unix systems uneasily, like the giant flying saucer in Independence Day, provoking complaints from co-workers that you were hogging megabytes of memory and making the VAX slow.
vi, by contrast, was just a display editor. If you wanted to refill a paragraph in your email, you typed !}fmt to pipe it to fmt, an external process. To reformat a block of C, you could use !%indent. (And you could map a key to this as a keyboard macro.) If you wanted to script some editing, you might emit an ex or ed script, probably from a shell script. If you wanted to concurrently edit a second file, you would start a separate vi process. You could run it on a PDP-11, where no process could exceed 64K. Unix philosophy: tiny tools, loosely coupled—though vi was a bit on the fat side in order to get WYSIWYG instantly responsive editing like Bravo, Smalltalk, or EMACS.
Vim is an extensible, customizable, self-documenting display editor, that does hairy things like turning your compiler error messages into hypertext and syntax-highlighting your code—a massive amount of functionality tied up in a single garbage-collected process with many embedded scripting languages, with potentially hundreds of files open at once, using megabytes of memory. If you want to refill a paragraph in Vim, you probably type gq}, which invokes Vim’s internal paragraph-filling code, not an external process. It uses the vi command set, with enhancements, but not the vi design.
Not that that's a bad thing. I greatly prefer Vim to vi. I've been using EMACS since 1990 or so and vi and Vim since 1996—I couldn't afford to wait 30 seconds for EMACS to load over NFS on my SPARC 5 every time I wanted to reply to a mail.
I hate the price and subscription model, and the learning curve has some steep spots, but once you're up and running, it's fantastic. I want to like Inkscape, but I've hit too many weird bugs (text getting squashed, transparency disappearing randomly). I'm curious about Affinity Designer though.
I was a long time Illustrator user. I think before the subscription model, say around CS3, Illustrator was fantastic. Then they started changing things in the UI that didn't need to be changed. I'm not against adding features but unnecessary changes really annoy me. I've been using Affinity Designer for the last year and I think it's great. It doesn't have all of the features Illustrator has but you can do real, professional work with it. Inkscape doesn't even come close.
Personally, I yearn for a command line image editor. ImageMagick is nice, but it can't do everything. Once you've gone cli, it's hard to go back to gui applications, since they're so inefficient.
I don't really know what "mask" and "extract" mean in this context. If you mean arbitrary selection of shapes then I have a couple of ideas how it can be accomplished. For mouse use I know the theory of arbitrary shape selection, but I never can get it quite right, since moving the mouse around the shape is very difficult for me.
> prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business
True - and this is why the huge software spend rarely produces productivity benefits. Because the software-enabled workflow should be different from the pre-software workflow.
But every organisation has two parallel workflows: the one written in the manual and the one everybody actually performs. The more rigid the organisation, the more likely these are to diverge. In a paper-and-humans system, the humans can make up for the deficiencies in the "official" workflow. In the automated system, it's baked in.
Lots of big failed deployments replace a human-judgement system that was working "unofficially" with a machine-implemented one that doesn't work at all, because the process as written didn't work. And of course it's impossible to tell management that the process doesn't work in that kind of environment.
(Hence the huge advantage of Kaizen - make the official process match the one that actually works for humans)
What you say sound more or less the same as what the Twitter thread says. Enterprises with complex and unique workflows come to a software vendor with a checklist of features, and complex highly configurable software checks all the checkboxes. It doesn't matter that the software is almost impossible to use. For some reason, usability is never one of the checkboxes.
The root of the problem is that the people holding the checklists are not the same people who have to use the software. Which was the point of the Twitter thread.
It's not just organizational complexity either; sometimes it's just scaling concerns. And sometimes it's not your original target market.
One company I worked for had Google as a customer when it was very small, and of course, as Google grew like a rocketship, used the product at a scale well past where it was used by anyone else. And then comes subtle little features to help them manage it at their scale. At one point, I think there were around a hundred "secret" undocumented options and another hundred "super secret" options.
Needless to say, complexity is just something that has to be managed, and there are always rational "business justifications" for practically everything. The complexity often isn't designed; it's just brought in one step at a time from a variety of places. And _that_ usually ends up in a pile of crap.
Enterprises think they need and exert more control than they need. I think companies perform better with less rigid “do it this way because.”
It’s fascinating how enterprise staff follow processes they don’t understand to get an outcome and don’t know why. I can frequently get better service than my IT staff from free tier consumer stuff.
I hear “security” blah blah blah but the security on gmail is better than any local outlook install. I think there’s a myth of security.
Whats breaking this is just people ignoring enterprise IT, I think, until someone notices they are spending lots on stuff that people don’t care about.
I don't know about gmail vs outlook, but I think security is often a valid concern. B2B products are usually built with a heavy emphasis on the security side of the security-convenience tradeoff. B2C products tend to be more convenience focused. You can have a B2B or a B2C product that is both convenient and secure, but that certainly isn't guaranteed, particularly for young products.
For instance Slack is great IMO, but they only introduced bring-your-own-key earlier this year (a requirement for security-serious companies).
> I think this gets it wrong. The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining.
No, that's not it.
Take something like filing taxes. The tax laws are very arcane and convoluted. And yet, we can take something like TurboTax that (if we disregard the upsell dark patterns) can make the average joe competently file their taxes. It has wizards to guide you step by step, it will hide crap that is not relevant and not even prompt you for it.
On the other hand, there are some countries, like Brazil, with their own government supplied software. Compared to TurboTax, they are a nightmare. There is zero guidance on what you have to do, they have all fields you may ever need in any tax situation in your life. The only thing it does competently happens when you press "send". That, and importing older returns (kinda, sorta, provided you have explicitly saved the old backups in the correct format, or you have last year's version installed).
> very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable.
Sorry, all I hear is a bunch of excuses. You don't need to have billions of dollars, all you need to massively raise the bar is to have a UX team – or frankly, a single UX person that is listened to and is able to engage with actual users.
I think that this hits the nail on the head. That often the bulk of the people who use enterprise software are not the true end-user.
Think of Salesforce which people who use it complain about daily. The end-users are actually all the people who get the reporting and sales management out of Salesforce. They love it as a tool. The sales people are only data entry people... Therefore its optimized towards the true end-users.
Sometimes I wonder, what if we just fundamentally took a new approach the OS.
Today at the root of your operating system is the file system. It would be interesting if the file system was changed to essentially the concept of a simple object store. In much the same way we have "standard file formats" today, we could move to something like a "standard class". Objects would be a first class citizen in the OS. I think this becomes more interesting too if you start to ignore where the object lives. It doesn't matter if an object you care about is local, or on a server in your enterprises network, or if it's a thousand miles away.
The second big change, is I would do away with "applications". opting instead for a smaller unit of executable. Probably integrated with the object system. The idea here is you don't buy an entire system from a single vendor. You buy features from multiple vendors... and the design of the OS makes it really easy to integrate together. I guess this is kind of the unix philosophy... but maybe taken to the next level.
Thirdly, I think it would make sense if the system was natively "reactive", I think that would help with making aspect-oriented programming more normalized.
Filesystems that abstract away things like directories aren’t new, they just haven’t been commercially successful (I believe Vista was going to include WinFS, which was a database-like filesystem, but it was scrapped). It’s not that systems research has suddenly stopped, it’s that it’s really really hard to not only introduce radical ideas to the public, it’s also hard to make sure you don’t break existing billion-dollar systems at the same time. And as anyone who’s had the misfortune of using a network share over a flaky connection can tell you, abstracting files away over networks is tricky business, and when your connection fails (which it will), that abstraction breaks.
Mmmmm. I used to think that. It sounded good but ended up being a pain in practice, and very confusing. The intent was right (ha ha) but the implementation was lacking in some ways.
As others have pointed out, what you're describing isn't a fundamentally new idea or even that revolutionary. You're basically describing a database filesystem. Onne Gortner attempted an implementation of this concept in 2004 as part of his/her master's thesis (see http://dbfs.sourceforge.net/). Systems like Spotlight are effectively a partial implementation of this concept- OS X essentially has a hybrid setup where there's both a database and conventional filesystem running in parallel. Going back further, locate (first implemented in 1982) could almost be viewed as a proto-Spotlight. Gmail's labels/tags are another example of a mainstream implementation of this.
the larger point is more interesting here. enterprise software sucks because it generally has to fit within the well-accepted boxes in order to meaningfully interface with all the other stuff. that implementation might be a little better than the last one...
but what if the overall model/structure is really what sucks?
I think it's spot on. Anybody who has participated in an enterprise sales cycle knows it's a ridiculous game of checking boxes created by random stakeholders who all need to have a say because they're Important with a capital I. At a certain point even a dev team with the best intentions can't create a usable piece of software with the resulting incoherent set of requirements.
> writing complex, highly configurable software is hard.
Especially overtime! And especially when different parts of the elephant are done to please different customers! It's hard to manage tech debt and feature creep when the software is being pushed in 4 directions by business, even if business has VERY close relations with customers (like companies I've worked for do).
This is the exact opposite of the advice I've heard about how to successfully deploy SAP - while it is endlessly customizable and you can staff a large, doomed engineering project to customize it to fit your business, you are a lot better off adopting the workflow and processes SAP wants you to use than adapting SAP to what you've been doing internally.
This is very true. The other part it misses out is the impact of sales process on product development. Enterprise software companies have large dedicated salesforce, and product managers are under pressure to deliver a feature that will close a large sales deal. I have been there, and we have compromised many times to satisfy a Walmart or a GM because of large $$ associated with that account.
Also, the data in our systems actually don't belong to us. So it was very difficult to run any kind of experiments or metrics to understand product usage to improve usability. You basically have to launch something and hope it works.
Finally, enterprise software companies invest a lot more on sales force vs. software development. Which compromises the quality of the product.
I don't think it's either/or. You make a good second point.
We have ServiceNow where I work. It is, in a way, SUPER customizable for tons of workflows... if you don't mind your workflow/work request being labeled a "shopping cart" with a "checkout".
Meanwhile, my team has an internally built request system. Bottle/SQLite (later converted to mssql). Built it with three people in three months with feedback from actual users (requests and fulfillment). It is so good, other team who were forced onto SNow were and still are jealous.
There are some downsides to maintenance, and it still doesn't have the API we wish it had, but damnit if it isn't 100x the form they built out for us in SNow.
This gets it right in my experience. I worked at a company that used Siemens Teamcenter. It's awful awful software, based on Eclipse but somehow even slower. Everybody hated it.
I once put a slightly sarcastic comment on an internal wiki about it being rubbish (literally everyone know this), and to my surprise got told off by some purchasing manager somewhere - I wasn't allowed to criticise Teamcenter because some important people higher up had made the decision to buy it.
The fundamental problem with enterprise software is that the buyers are not the users. Why would you care about usability if the people you are selling your software to never use it?
> they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel
Interestingly, Word and Excel were the origins of OLE in Windows 3.x times that was meant to allow embedding documents of one application inside another so that each application can focus on doing one thing well. The original documentation even explicitly wrote something along these lines.
I always thought that OLE was basically Microsoft's attempt to bring Unix's "do one thing well" composability to GUI applications.
(things changed considerably with Windows 95 and COM though and that part about doing one thing well was removed)
Blackboard's roots were in the NPO/NGO world, which influenced many design and feature decisions that took them in a completely different direction than B2B SaaS.
OP conflating them with enterprise software is not the best premise.
In my experience with most Enterprise software, the problem isn't the number of features it's the total lack of discipline in deciding what features are actually needed. Jira is the worst at this because people throw spaghetti at the wall until they get something that "works" for PMs but nobody else understands. I've worked at exactly one place that really was careful about JIRA and what made sense from the tool and it was a joy. I imagine the same is true of Salesforce though I've never seen anyone actually pull it off
You raise a good point, but it doesn't mean the OP is wrong. There is an inflection point where, even if the software was originally designed with a target user (persona) in mind, the features that keep getting added are designed for the buyer. It is impossible to design software that works for wide set of personas.
very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable.
95% of "enterprise software" is typically a small developer team of 5-10 people that delivers a product with some features, usually developed in and around J2EE, CORBA, COBOL, etc. It's then sold and supported by a marketing, sales, conference, booth, and sales engineering budget of billions of dollars. Haha!
The other 5% of enterprise software is what you described above. :)
On point! And so begins the large IT company lifecycle...
- Those hundreds of sales engineers weave a spaggeti junction of pseudo products around the core application to suit the whims of the C-level clients and their buzzwords of the month
- The company gets frustrated when this begins to break down leading to sales delays and embarks on a disasterous rearchitect which pits the sales engineers (microservices!) and core engineers against each other.
- The sales delays lead to cost cutting and the old guard make a timely exit with a nice package. The laid off sales engineers get a better gig due to the buzzwords on the cv.
- At some stage in the old guard are brought back to maintain the old core that is still running the company, but now charge a hefty consultant rate.
The Pitch: "Structural support framework product! It's fully extensible and can conform to any design requirements unique to your business requirements. It's worth the price premiums for its amazing flexibility!"
The product: 5 thousand dollar bags of concrete(cut with flour). Just add water, re-bar, molds, trucks, cranes and workers and your all set!
Construction is complicated thing, 5 grand ain't unreasonable for a structure that could be around decades right?
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining.
Bingo—the dysfunction of the software reflects the dysfunction of the organization.
No, it can just be one or two bad decisions that cascade and wind up being hard to get undone. The decision might have come from a committee or might have come from a single executive that turned out to be a bad hire.
SAP migrations often fail after millions invested because SAP prescribes a business model and if you want to change it you'll pay out of the nose for consultants trying to tailor it to your special snowflake business
I second this. Writing custom software for a few users with complex and custom business cases is very hard. UX goes out the window because of the large feature set and the low productivity of each programmer.
While I agree in general, I'm not sure SAP is the best example - in enterprise circles, SAP is famous for forcing you to change your workflows and processes to fit the SAP model.
Unix philosophy tools are the best building blocks for software engineers, but enterprise software is primarily marketed to companies that see involving SWEs as a last resort.
I think there should be a distinction between commercially high revenue software and software that is simple and effective. I'd rather call the latter succeful.
No these tweets get it exactly right. A problem is software that gets sold on golf courses without any regard the people who are actually going to use it.
Also, since you name jira. Try doing a so-called 'bulk change' in jira for, let us say, three stories, and marvel at the needless sequence of screens one is guided though. It has nothing to do with any necessary complexity. It is just bull$hit software being sold at golf courses.
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining.
Call me cynical, but as I see it the complexity of the problem grows to fit the number of dollars available. If it's a large organisation they will invariably choose something that takes a colossal number of people to install and maintain it.
I've seen this as a person who designed and built cash registers. Supermarkets selling 10's of thousands of products can only tolerate a limited amount of complexity - so they have the simplest systems. Liquor markets has less products, and so they start branching out into weird pricing scheme (eg, mixed dozen of certain wines - something a supermarket would never contemplate). Go to a restaurant and limited products, and hell even McDonald's will even create a product especially for you on the spot - how many patties would you like on that quarter pounder Sir? A regular restaurant creates the most insane products you've ever seen - how would like it cooked, what sauce, kids meal, and even "which of the items on this bill will your friend be paying for?"
You could argue this complexity does help sales in some way. Bureaucracies are special they add totally unnecessary complex to justify their existence. So the article gets it right in one way: in order to justify that ongoing money in people needed to maintain it they need a product that cost a lot, and so justify that it needs to have a lot ticked boxes. It is in the products makers interest to make the task seem as complex and yet attractive as possible.
Or to put it another way, a big organisation invariably consists of a number bureaucratic fiefdoms whose evolutionary imperative is to make themselves indispensable as possible by ensuring their is work that must be done by them in order for the corporation to function. They are constantly trying to grab work from each other in a dog eat dog world. The worst at it get eaten by the best.
I recently saw this first hand. An organisation is installing SAP for payroll. It's taken a team of 10 or 20 3 years so far, and it's not done. Hmm, I thought, they must be big. Nope - turns out they have a total of two offices. I could write a system that serves the payroll needs of 200 people in 2 to 3 years, and it would be customised to their exact way of operating and would only take one person to maintain it. So why SAP? They only reason I can see if a bureaucratic mandarin can pull getting it installed, he's got a guaranteed job managing 20 people for years with plenty of opportunity to grow it.
IT bureaucracies seem to be particularly cancerous. I suspect that is because most companies core competency isn't IT, yet reducing head office staff through automation depends on IT and everybody knows that. So IT can get away with more in the way of snow jobs than most.
> prefer to buy software that they can fit to their workflow rather than change
Existing users' familiarity with existing tools and the ability to accomplish existing tasks with existing skills are all part of the competitive landscape for any tool that must compete for people who use it by choice. In other words, if the user chooses the tool, they will choose a tool that allows them to accomplish what is necessary, given their existing skills. That this choice is so often lacking is just a symptom of the reduction of individual agency in the modern corporation. There is no fundamental law preventing software from becoming more usable and more powerful over time.
In fact, for as often as enterprise procurement keeps old interfaces around longer than they should be, it is just as often responsible for replacing something that everyone knew how to use with something worse, rendering institutional knowledge worthless overnight.
> most successful software of all time
By what definition of success?
> People hate them because they are complex, configurable, and have 1000 features.
> But that's the same reason they can [meet the need.]
Good design is precisely about enabling complex work with well-chosen, simple yet powerful tools. Your statement implies or at least suggests that any tool that meets a complex set of business needs must be something people hate, which is equivalent to saying that well-designed tools cannot exist -- equivalent to giving up on design.
All the evidence shows us is that good design is rare, and much more so whenever tool users are not tool choosers.
If you believe good design is possible (as you suggest later, that it is just expensive) then what you're saying is simply that bad design is cheaper, and is the default outcome when good design is not valued, all of which is certainly true. However, you still have to explain why good design fails to thrive in the market, and why large numbers of people are using trash tools that everyone hates and no-one could ever love.
This may be explained by the principal-agent problem, by network effects, as in the case of platforms and productivity tools, by a lack of user awareness, or various other reasons, but simply saying that good design costs and doesn't happen by accident is not a sufficient explanation for what we see happening in the market. You might believe that the market is correct here, and good design simply isn't worth the cost, but it wasn't clear to me if that's your position.
> That the end user isn't the purchaser isn't going to change that fundamental reality that businesses are complicated.
The fundamental reality here is that good design will only be rewarded when the people who suffer from bad design are empowered to choose otherwise. As long as the cost of good design is borne by party A, while the pain of bad design is borne by party B, and party A pays for and chooses the tools, then bad design will continue to dominate.
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 stack and need a 1:1 rewrite”.
Big ships turn slowly and change is difficult. UX isn’t valued. Agile is really waterfall and when a big is found it’s always a critical showstopper. Enterprise is a different beast altogether.
When I worked at a Fortune 500 company, even finding someone capable of creating a good UX was difficult. We used ServiceNow for our CMDB, and since Infra "owned" that, our customizations were done by SysAdmins that were "repurposed" into devs through the course of like a month long training with ServiceNow, despite them having never done any development.
The result was that our ServiceNow pages were horribly long to load. The "devs" complained that it was because ServiceNow's database was slow, and said ServiceNow said they couldn't make it any faster. I did like 30 seconds of digging and found out that every. single. Javascript request. was made synchronously. The reason it took 7 seconds for a page to load was because it had to execute a series of like 15 HTTP calls to get data to load the page, and each one was waiting for the one before it. The library they were using even exposed the methods with a name something like `synchronousGet`.
I don't think ServiceNow could have possibly returned results fast enough for that to not be painful. The requests had to go over WAN, there was like 100ms of latency just on the network connection. Even if ServiceNow's response was instant, we're still talking about a couple of seconds to execute that many requests.
My takeaway was that at most Fortune 500 companies, the perks aren't generally great (pay is lower than a lot of tech companies, the perks are generally few) and it's hard to get fired. So those who excel will move on to greener pastures with better pay/perks, and low performers are difficult to get rid of. Through attrition, you gradually end up with an employee base mostly made up of those who can't or won't move elsewhere, who do silly things like design architectures that are fundamentally incapable of HA, or writing webapps with entirely synchronous Javascript. Not that there aren't exceptional people within those organizations, however the IT department is defined by the majority, not by its most competent member.
You're assuming that the cost of human capital actually matters in big corporations. As someone who has worked for several Fortune 100s and a couple of government agencies, I assure you, that is not the case. Employee time is treated as having no value, and things that damage the efficiency of employees are not relevant.
I once saw a "cost saving" round prohibit our team's QA engineer from getting a new SoapUI license (we were supporting an API!). It took three five-person meetings to get official approval to buy a $100 license - at a human capital cost of thousands of dollars. Not an eye was blinked at this absurdity.
Along the same lines, I once saw a lead architect go through the same nonsense to get a $100 Adobe Acrobat license (at a government agency). He said to me "It's easier for me to spend $100,000 dollars than to spend $100". He could have asked for a couple of new heavy-duty Unix servers with Oracle, and gotten it approved easily. But Adobe Acrobat? No, that's waste!
It works in the other direction, too. I've seen (and been in charge of) a depressing number of projects that spent hundreds of thousands of dollars' worth of people's time on writing an in-house replacement for a piece of software that cost, at most, tens of thousands of dollars.
My working hypothesis is that management types don't really think the costs are comparable, because licensing fees are an operating expense while in-house development costs are a capital expense. Which is true, but I imagine in-house development is a tricky thing compared to other capital expenses, since the final product generally has zero market value.
It is absurdly easy to burn through thousands of dollars worth of employee time. Call something “review”, “emergency”, or simply discuss the colour of the bike shed. Everyone has an opinion on that.
Now invite all sorts of heads, leads, and other important people. Done.
I did consider setting up a mock meeting just to make that point. Let’s see.
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.
You have to careful with this. Things that sound like good ideas to the programmer can often be bad ideas for the user.
Case in point: a customer (we do embedded design services) came to us to redesign a manufacturing tool and mentioned that it was used both in the US and Costa Rica. We suggested adding Spanish language screens because, well, it lets more people in Costa Rica use the device.
Problem was, the users pushed back because knowing English got them more money and they could be replaced by cheaper Spanish-only speaking people if we added the translations.
To the point of making money on the ECO's, the problem is that if all your competition is structuring their bids this way, then you have to do the same if you're to have a hope of winnning anything.
In a company of that size, there's literally nobody who would be receptive to such an argument.
End users don't really matter, because they're not in charge of these decisions.
Their managers have a bit more clout, but they're almost certainly not in charge of the vertical that writes the enterprise apps, so they're still not really in charge of these decisions.
Developers writing in-house apps are swamped, both by incoming requests and by paperwork and suchlike. There just aren't enough of them to be able to spare the resources to worry too deeply about UX. Besides, none of them is actually a UX person.
Their managers have limited budget, and can't afford to be allocating resources toward UX. They're worried about their own bottom line, and increased costs due to poor UX invariably come out of someone else's budget.
Whoever's in charge of in-house development cares about these things in only the most abstract of ways. They definitely don't care about individual apps and projects; they're just allocating the resources they get. Which aren't many, because in-house development is a cost center.
The executives in the C suite probably exclusively hold the power to re-allocate budget toward a more optimal solution, but they really, really really don't care about these things. As they shouldn't - the actual dollar cost associated with any inefficiency due to sub-optimal in-house app UX is probably way too small to be worth their attention.
As someone who wrote internal software for a fortune 100, probably all of them. EDIT: When I first read your question, I thought you meant 'which companies?', now I realize you're asking who to talk to within a given corp. The answer to that probably boils down to 'whoever is getting bribed with kickbacks from enterprise software makers'
The people who set the requirements for my biggest project tried to massively expand them about 2 weeks before the end of the project, then tried to bury it after we instead focused on polishing UX and debugging for those 2 weeks. Several years later I hear it's still in use internally and the users refuse to migrate to a third party solution despite pressure from execs who probably want kickbacks.
Giant corps have no idea what the difference is between usability and number of features.
It drives down costs at scale when you can amortize the UX work over many users. A lot of enterprise applications, are built for a small number of users so it doesn't amortize as well.
Most of the time it is either a small number of users, or it is not used that frequently.
Since developers/designers probably cost more than the end-users of the application, most businesses consider it OK to push that cost to the actual user.
Once people become accustom to using a piece of software, it doesn’t matter. I witnessed this first hand, we wrote software for field service techs running on old Windows CE based ruggedized devices. The techs could navigate through the Windows with the keyboard, 5 deep without waiting on the screens to catch up.
Training is already a line item and comes with the cost of the software. "Good" or "easy" training isn't valued as compared to the feature checklist, and it never will be. Unless the buyers of the software are accountable to the users of it, not the other way around, nothing will change.
I agree with all you said but you seem to be referring to internal apps only. The blog talks about enterprise software of a broader scope, things that are built by a 3rd party and the purchase is decided by people that won't be the main users.
I'm not sure where this originates from, but the most succinct definition I've heard for "Enterprise Software" is that the person who pays for it isn't the person who uses it.
I have a friend who works in a sales role for IBM. He told me that part of his bonus is contingent on being able to prove that the customer has actually installed the software which they bought.
The policy apparently arose because certain public sector entities had refused to consider new deals since they still hadn't got round to installing the software for which they had paid millions of dollars, years before.
I’d bet good money Watson got sold to a bunch of companies who wanted “AI” then they didn’t do anything useful with it.
It was a smart play by IBM, the sales guys want to say AI and machine learning, so give them some generic crap which gets loosely integrated into parent projects and they can have a field day on the phone selling it.
Watson would be a perfect study on modern big business software that these billion dollar consultancy companies engage in.
Plus IBM makes even more doing the “integration” than the original sale.
I'm almost certain that Watson was a series of Python and Prolog "scripts" that were packaged together with big black boxes, blue lights, tagged as AI, and run through the IBM sales and marketing machine.
The result was huge margins for IBM and customers scratching their heads afterwards.
And I'm sure the problem is now that a lot of places installed it but never used it.
One of the things I like about SaaS software is that a subscription revenue stream is more closely aligned with actually delivering value than a long-term sales model is. It's still not perfect, but I'll take what I can get.
This is so true. Whoever buys it usually checks off a list of features that it needs, but has no idea if it does any of those things particularly well.
I've seen this with mobile phones in the 90's-2000's. Until Apple came up with the iPhone designed for the end users, the phones' buyers were the networks, not the end users.
The same goes for companies like LinkedIn - they are now driven by recruiters and not the end users. Thus the idiotic interface and functionality changes that basically makes it unusable [to the most of the users].
Apple's iPhone also brought new UI/UX ideas and people that grow up with these phones/desktops now and judge everything by that standard vs. what was considered "working" way back when. Android and Microsoft helped too. This industry shifts fast, so it's really no surprise people come to hate the older stuff by looks alone.
As someone who wrote code for two mobile handsets for two different companies in the referenced time frame, I would say there was a noticeable lack of innovation in the handset business.
Except, perhaps, in Japan - where mobile handsets were way ahead in terms of design and features as compared with the U.S.
Which, I think, can also be explained by the fact that the handsets in Japan were marketed to the end users as opposed to the U.S. where the buyers were the network operators.
Not sure I agree. There was a lot of innovation on smartphones before the iPhone, they were just not as visionary as the iPhone was. Look up the Nokia N-Gage as an example
I don't think he means software that is necessary for the business, I think he means if it specifically enables a profit-generating function in a business.
If you're FedEx, you don't buy someone else's logistics software package, you build your own.
I've heard you're saying and I think it's succinct, but a simplification of what's talked about in the post.
My example is when looking at daycare for my kid. They all boast about this app the teachers use to take pictures, update about their day, what they ate, when they went to the bathroom. In practice, each some teachers did it more than others, some none at all. When I would watch them, they'd be taking pictures with their iPads and spending time filling things out in lieu of other duties like watching the kids (although, most updates came during nap time after they had tidied up).
It pitches really well, but not quite necessary, and is often a huge time suck. I often still ask questions that app could answer (when did they have an accident, what happened? Did they eat all of their lunch? Did they nap today?) but I don't need a tedious record, just an occasional checkin.
I agree, I had this discussion with a coworker the other day. So many tools are used because either an executive got marketed to effectively by the tool provider.
This is missing a big part of the dynamic. Much enterprise software is what Joel Spolsky describes as "internal software"[0]:
> Internal software only has to work in one situation on one company’s computers.… Here usability is a lower priority, because a limited number of people need to use the software, and they don’t have any choice in the matter, and they will just have to deal with it. Speed of development is more important. Because the value of the development effort is spread over only one company, the amount of development resources that can be justified is significantly less.
So, a lot of enterprise software sucks because it simply doesn't make sense to make it decent. No matter how directly the end users communicate with the developers, this won't change.
The economics of internal software don't apply to products like Blackboard (which would go in Joel's "shrinkwrap" category), but the vast majority of enterprise software is internal and thus sucks for reasons entirely unrelated to this thread.
> Games are unique for two reasons. First, the economics of game development are hit-oriented. Some games are hits, many more games are failures, and if you want to make money on game software you recognize this and make sure that you have a portfolio of games so that the blockbuster hit makes up for the losses on the failures. This is more like movies than software.
> The bigger issue with the development of games is that there’s only one version. Once your users have played through Duke Nukem 3D, they are not going to upgrade to Duke Nukem 3.1D just to get some bug fixes and new weapons. With some exceptions, once somebody has played the game to the end, it’s boring to play it again. So games have the same quality requirements as embedded software and an incredible financial imperative to get it right the first time. Shrinkwrap developers have the luxury of knowing that if 1.0 doesn’t meet people’s needs and doesn’t sell, maybe 2.0 will.
The first part of that's kinda true, but DLC means the second part isn't. People will pay for what amounts to a point upgrade for game software.
When I click on Course Tools on Blackboard, I get a bewilderingly long list including:
Basic LTI Tools, Blackboard Collaborate Ultra, Brainfuse HelpNow, Cengage Learning MindLinks (TM), Content Market Tools, .... what are all of these things?! I want to track and post grades (and export them to a spreadsheet), mass email my students, post a link to my syllabus and homework assignments. That's it.
Meanwhile, with our recent "upgrade", the option to merge two sections of a course (so that I can email both at the same time) went away. I have to email our tech support (?!) to ask them to do this. Apparently this was supported by a plug-in module (??) from a third-party vendor (??!!!) who went out of business.
If merging two courses is so difficult as to require a third-party solution, then I have to wonder about what Blackboard's codebase looks like.
Never mind the useless crap. You’d think the spreadsheet used to enter grades — a core functionality, and the only essential feature I need for a course (everything else can be replaced by a mailing list) — would be at least halfway decent. Nope, it’s the single most horrifying spreadsheet implementation I’ve used in my life.
User-design indirection is a tremendous problem. It's a form of the principle-agent problem, or of what I've been noodling at under the general category of "manifestation", which is the idea that there are problems which are obvious and evident because they are manifest: immediately apparent, visible, obvious, observed, experienced, felt. And those which are not: nonapparent, invisible, non-obvious, unobserved, not experienced (in the future, by others, elsewhere), unperceived.
Nonmanifest problems are a substantial class of hard or big problems. Things which are outside your own experience, or the experience of administrators, managers, judges, or executives (in the broadest senses of the words) are really, really hard to understand, grasp, or appreciate.
(This is a key argument for diversity, real diversity, of experience and background on your team(s).)
Two specific examples, both trivial, though illustrative, come to mind. One was a flyover-state hotel I'd stayed at recently during a road trip. There were numerous obvious design flaws of the building, ranging from the entrance (no way to get a wheeled luggage trolly up the steps) to the interior layout (lack of lifts, floor plan) which strongly suggested some architect and design committee who'd never visited the site having designed the facility.
Another was a pool party years ago at which a guest suddently exclaimed that something had touched them, under the water. Nothing was visible. Then a second and third made the same comment. The culprit? A clear plastic drinks tumbler, which would oscilate when touched, given the mass of the water it moved against, giving a lifelike contact response, but being all but invisible in the pool itself. Until directly experienced, and ultimately revealed, the effect was difficult to credit.
Though the tumbler was invisible, and hence, not perceptible. You could go through any number of cases of phenomena throughout history, such as the germ theory of disease, prions, electromagnetic force, subatomic particles, or mental health, all of which have, at least by current reckoning, some level of cause or mechanism, but which were seen as beyond description or explanation in the past.
The case especially of moving from some sort of divine or moral explanation, as has been the case for both infectious and (somewhat still the case) mental illness is a critical one. Similarly for natural phenomena (comets, asteroid impacts, earthquakes, volcanoes, cyclonic storms), often seen in the past as portents of the gods / a god, rather than events with specific causal mechanisms.
There are several Big Problems currently facing humanity which are straddling this manifest/not-manifest cusp, with media manipulation and global warming being two of the more prominent.
Pretty true. For example, some of the worst applications I have ever used are by far timesheet applications.
It's a product with a completely captive audience, that cannot go to the competition. If you don't fill your timesheet, you don't get paid its that simple.
Typically these are either built-in house, or are an expensive third party product with terrible usability, bought by managers who might not even have to use it.
If an application's audience is captive which is by definition the case of most enterprise applications, there is no incentive to care about user experience, unlike public internet applications.
Sadly, this isn't pessimistic enough. Many of us have experienced having to fill out multiple timesheets in different apps.
Fill out company timesheet, connect to big-company VPN, log into their site, fill out timesheet there. Because creating an integration requires both companies working together, which obviously isn't going to happen.
I recommend learning to use webdriver to automate things if you ever have to do this. It'll likely be a net time loss, but you'll feel better about things.
Timesheets turn out to be a very complicated product.
1. integration with accounting and payroll systems is mostly tragically difficult (and excruciatingly boring).
2. companies have wildly different needs for data entry and validation.
3. Unions in particular create fiendishly complex requirements for hours etc.
4. A captive audience means you can't drop "problem" users, and you do need to support outdated browsers and devices.
5. Timesheets need to be reviewed, revised, authorised. There needs to be a solution for when the manager is on holiday.
... And so on for another 20 items that are similarly complicated.
Timesheets are a great example of something that most people have used and think they understand (and I've seen software devs build a product for) but it turns out to be a far far harder problem than it appears.
I wholeheartedly agree. I think part of the reason I ended up on the product-software side of design was that the timesheet software our agency used was infuriatingly bad. It was like a windows-web port. I'd have to bill an extra quarter, just for the time it took to put in a change order.
Ditto with job applicant portals. They have a bunch of weird features for doing obscure HR stuff like internal approval chains, but terrible UX for the actual applicant. Would it be so hard to handle applicants whose resume is a url?
A couple of years ago, I was applying to work for a big government contractor, and even though they wanted to hire me, they couldn't figure out how to move forward past the "contigent job offer" phase in their new hiring software. I ended up taking a job somewhere else after going back and forth with HR for over a month as they tried to figure out things on their end.
I had a contract where the recruiter apologized in advance for the onboarding process. It started with not being able to create an account with the e-signature vendor with whom I had an old, deactivated account, and being unable to get the bureaucracy to send the paperwork to a different email address. It went downhill from there.
Yeah, I believe it is Taleo where you have to re-enter all the info from your resume multiple times as you go through a 6 step portal. I absolutely hate that interface although thankfully most places I want to work at now don’t use it anymore
I don’t know the name of it but I’ve seen a lot of places now with a single screen portal which I love, just enter your name, answer the self reporting crap, maybe select what position/location you’re interested in, drop your resume, and you’re done.
I have no idea why that wasn’t the flow from the beginning.
Yes, some job application portals are extremely clunky, however, the most common job application portal I've seen as a job seeker is iCIMS which I actually don't actually have any major complaints about. That's also what my current and former employeer uses. The name is certainly clunky though!
Yeah, ours is hot garbage as well. I ended up writing a script that spoofed the client and talked directly to the backend -- luckily my timesheets are simple, same thing every week.
We were forced to 'upgrade' years ago from WebCt to BlackBoard. The worst part was not the feature set, but re-learning all of the things you already knew how to do.
So when the administration decided to hold focus group sessions on whether to purchase a new system (because the prices were suddenly raised, IIRC), a few of us got Moodle included among the choices, and then managed to convince our colleagues and the institution to accept it with the most convincing rationale: the price would never change and since open source software tends to be evolutionary for the most part, we probably would not face having to re-learn how to use the system again.
I don't think you would be surprised to learn just how easy it was to convince users to accept a system that's unlikely to experience massive change.
In any case, we've been using Moodle for years now. It's basically the same as when they set it up, and all my labour-saving import-export tricks have remained consistent over the years.
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 who tells the story was mildly inconvenienced this one time.
Fast forward a few decades and I'm a web developer writing software. My direct customer has a website where they want updates on various things from their partners. This site is entirely for their partner's benefit, our direct customer has a different site for the same data so that they can do more complex things. These partners are barely computer literate, our partners are "power users" (everything is relative here).
So of course this site I built that is dead simple because any complexity confuses them, and by most measurements (and my conversation with the partners) it is doing well.
Accordingly my direct customer wants like dozens of new fields, options to export data and etc ... all things that their partner's never do, didn't ask for ... and don't understand.
Meanwhile I ask the customer(s) about adding a block of text in a section of the site to help guide the partner's along better .... no response. (actually I've started just adding them on my own now...)
I put a lot of the things I find unnecessary / unused in places that stay out of the way of the user. I check the metrics and yeah, nobody uses them, so there they stay. In a way like a duck it gives them a place to make changes ... that is safe for everyone.
The listed reasons why enterprise software sucks are not terribly controversial, they are well known. Perhaps more controversially, here are some reasons why enterprise software is good and maybe even fun:
1. The domain that the software operates in is usually complex and varied.
2. The job that the software does is often meaningful, and helps people be more efficient or faster at a job, as opposed to simply entertaining them.
3. Users of the software are generally professionals, and can accept (and often demand) a deeper learning curve in exchange for more features.
4. It's generally more fun to develop software for smart devoted people than uncommitted interlopers.
5. Smart people using your software often directly challenge you to innovate (they make feature requests), rather than spending most of your time reverse engineering the psychology of your users based on aggregate behavior whom you rarely interact with.
6. Enterprise software often needs to dive deep into an industry or practice, they don't need to generalize to everyone.
7. This isn't a distinct benefit, but enterprise software does not need to be a large monolithic application, it can be nimble and fast moving like any other software.
No, it's really more complicated than "Built to appeal to decision makers, not actual users."
In terms of decision makers vs. users, the issue is that there is more than one group of users. For Blackboard, there are faculty, students, and administrators. There's a venn diagram of overlapping desires there, but there's also plenty of room for contradictory requirements.
Second is the nature of enterprise software:
--It's large, expensive to buy and expensive to maintain. So, you can't go switching it out every time a cool new product comes to market with new convenient features. You're stuck with it.
--But the vendor doesn't want to lose customers, so they figure out a way to bolt on the most popular things that come along, usually 2-3 years afterwards.
--The implementation is clunky and awkward and adds complexity for users that don't need the feature and maintenance of the system
The alternatives aren't great either: Pick an up & comer, like Canvas. It's smoother, more refined UI, less bloat, etc. People switch, because it does 80% of what they need very well, and they decide they can live without the 20% hardly anyone ever used. But over time, Canvas gets caught in the same trap. Users clamor for more features over time. They bolt on more and more, and the process repeats.
Sometimes a corporation (or university) will try to circumvent this. They go "best of breed" for all functionality
--They buy a minimalist LMS, they buy a separate system for advising & appointments etc., they buy a third system to replace the financial component handled by Blackboard Transact, etc.
--And, for a short period of time, users may be a little happier, until bolt-ons creep into each product, but maintenance & integration costs explode on the infrastructure side.
--If it gets too bad, someone in leadership will eventually say, "Why are we spending 3x as much on license maintenance with <X> full time employees to keep it all running when we can get one single system to do it all for us?
And some variation of the above cycles repeat over & over.
Administrators use it for data analysis on course usage, trend analysis in course performance, and other groups also us it for some types of financial transactions. None of it's great, most of it is minimally adequate.
Not sure about the generalization to enterprise software in general, but the critique of people choosing blackboard is spot on.
Before selecting a tool, professors should always ask: "is this the tool that two recent graduates would choose without my intervention?". Because to use any other tool is to deprive your students of skills they'll likely need.
Also:
> Once profs and students put down the pitchforks, committees will go back to their checklists, and feature creep will resume.
The solution is simple, don't put away the pitchforks. Keep them out until the people choosing the software inform the people that make the budget that that money would be better spent elsewhere.
If the professors don't know what tools those are, spend the money you're saving by not forcing featureful garbage down people's throats on engaging the studentry until the answers are clear.
Like maybe create work-study programs where students who know how to run the kind of boring website the web was designed for are paid to assist teachers in this task.
Every popular computer OS except android has an ssh client now. Just give the students and professors shells and have them put the documents in shared folders.
This is kind of a manifestation of this agency problem, though. We, presumably the people that would write this theoretical software, have a vastly different background than the people who will use the software (general students, not just CS students).
SSH is perfect for us; it's a well known and supported tool that's shared in countless other workflows. Can you imagine the struggles of an Art History student trying to submit a paper at 3am and getting a message back that host key verification failed? I suppose even before that, they would need to figure out navigation in SFTP. Or resort to a third-party GUI SFTP client; and the options that GUI will ask them for are probably bewildering. I can just hear them asking "What the fuck is a host/server? All they gave me is this stupid website, sftp-server.myuniversity.edu"
It’s common among chemistry students because of the incredibly expensive Unix software they use for calculating eg molecular orbitals. I’ve gone to their meetings and listened to them, they know little about computers and are taught to use ssh.
Created 2 days ago! I’d say I’m shocked this repo is still going strong, but with the amount of SaaS fodder geared towards dev teams these days, seems like we’ll never have enough time to incorporate them all. Throw em on the backlog.
Disclaimer: I work at Instructure, the company that makes the LMS Princeton is moving too. Opinions are my own, etc
First things first, Blackboard is some of the worst of enterprise software and a huge part of why they have lost so much market share is not only because they had a difficult and obtuse to use product, it is also because they were extremely aggressive in buying out any competition and EOLing their products and forcing schools against their will onto Blackboard.
And I think this is the bit that is often the case about the worst enterprise software is the it gets to a point where customers are so entrenched that the company behind the product has market forces that drive it to grow through unhealthy means that are often hostile to customers.
To his conclusion about all software tending towards these same problems, I can't agree more. It is a HUGE challenge to continue to deliver software that remains easy and friendly to use in light of the real need to add real features. You simply can't just ignore the market that thinks differently about a given problem and the workflow to solve it.
I think the right answer to this problem is not just really great product and UX (though that is critical), the real challenge is to figure out the underlying technology platform and engineering process that makes it cheap to build new features and compose them together without the complexity becoming overwhelming for your average engineering team. From what I can tell, this sort of architecture looks vastly different from how most software is started and how we think about software in general. Making that transition is one of the hardest things to do in engineering and it is what sets apart companies who continue to deliver well liked software and those companies that tend towards being defined by worst tropes of "enterprise software"
> a huge part of why they have lost so much market share is not only because they had a difficult and obtuse to use product, it is also because they were extremely aggressive in buying out any competition and EOLing their products and forcing schools against their will onto Blackboard.
Sounds familiar — that’s essential what Chegg did to all online reference management tools. They bough out RefME, CiteThisForMe, EasyBib, Citation Machine, BibMe, and probably some more that I don’t know off the top of my head. They then remove functionality from all the sites and shoved them full of ads for their other services.
As somebody who has:
(1) At a management level, chosen and implemented and defended unpopular and objectively clunky enterprise software;
(2) As a user, been riled by the utter degeneracy of clunky enterprise software chosen and implemented and defended by others;
(3) As a developer, had to splice additional functionality into crufty enterprise software;
I have come to the conclusion that the main reason enterprise software sucks is because those who choose it are not those who are condemned to use it, and draw benefits (such as additional data) without paying any of the daily costs in maddening workflows and utterly shitty user experience.
With JIRA (and most other enterprise ticketing/scrum sofware) EVERYTHING is possible but nothing is easy ! What I want to buy is NOT 1001 to log/validate/confirm/report a "login form" doesn't work issue. I want to BUY someone's workflow that has invested real time and research and optimised the workflow. The software should only have a supporting minor role in this workflow-product.
Its like buy a super-duper-expensive-hi-fi-amplifier... I don't want 9 dials to control the tone and bass. I will never be as good as the sound engineers as NAD. I want to buy THEIR tone expertise ! i.e an amplifier with an on-off and volume button.
We are pretty much building this. We want to optimize the workflows so they actually make sense and recommend best best practices. The main thing we want support is individual's and the team's momentum. If the team has momentum, it's feels good and overall the company will make more progress. Features or anything that get in a way of that should be automated or not added at all.
Looks good... but if you want to sell me (based on my first comment)..The word(feature) "issue tracking" should not be the first thing I see. I again "see" just another "issue tracking product" ( with a slick interface). Sell me a workflow-process not software.
I used to work in higher ed and dealt with the awful Blackboard system.
For reference as to how bad it was, different modules used different database vendors (MSSQL vs Oracle).
Also here's a comment I had left myself about how to work with dates in the Oracle db (aka the Blackboard Transaction System, aka BBTS):
# BBTS doesn't use a date,datetime, or time column from its database.
# Instead, it uses a float that is the number of days since 12-30-1899.
# The Ruby Time class is ideal for handling this, but the Ruby Time
# class doesn't work for dates before 01-01-1970.
# The magic number is: TransactionSystem::MAGIC_DATE_NUMBER (25,569)
# If BBTS is below that number, we must use the Date class.
# If BBTS is above that number, we will subtract 25,569 from the BBTS
# and start counting from 01-01-1970 instead of 12-30-1899.
# Dealing with dates before 1970 will take much longer to process.
It's like how the decision to write a blog post as a series of tweets is really easy for the writer who doesn't have to deal with the task of reading a series of disjointed blurbs of text.
> "Software companies can be breathtakingly clueless when there's a layer of indirection between them and their users."
Any product where the users or consumers of the service are not the target market is horrible and becomes misguided on pricing and functionality.
Enterprise software is surely caught up in this mess of usability not tuned to their actual customers that have to use it. There is some abstracted target customer above the actual users that clouds the usefulness and utility of the product.
You might say in the US that we have enterprise healthcare, the target market should be consumers and doctors, but the insurance companies target customer is employers and their own bottom line.
In the case of taxpayer funded deployments (i.e. government acquisitions) it's generally due to being built by the lowest bidder, coupled with an inadequate incentive structure to fix. This may also be the case in some corporate deployments.
It’s also being designed and implemented in a situation where 5 people plan and oversight the work of 1 person-ish. IT is pretty horrible about having lots of know-nothings with shiny job titles telling one or far fewer people who actually do the work and know what is possible that their technical objections or restrictions are false/made up/etc.
This is very true but also very well understood. Marc Benioff is selling to C-level execs who will probably never use the Salesforce software themselves. Same reason why Phil Mickleson is the spokesman for Workday. The people making multimillion dollar purchase decisions are playing golf and watching CNBC not sitting in a cubicle wondering why the software sucks.
This is the exact reason why I'm skeptical about Slack's future and why I think the stock is going to be troubled for a while. It's a rare enterprise software product that's beloved by the people who use it and to my knowledge doesn't do the same kind of lengthy multi-month/year "take clients out for steak" sales cycle. It seems to rely heavily on upward pressure from employees to gain traction. I'm not convinced that that strategy is going to be super effective, especially competing with Microsoft who already has massive enterprise sales teams with well-developed relationships with the types of people who make purchasing decisions.
Ben Thompson wrote a great piece a few months ago on why GCP is facing similar difficulties gaining traction in the enterprise.
"The point is, some products are sold directly to the end user, and are forced to prioritize usability. Other products are sold to an intermediary whose concerns are typically different from the user's needs. Such products don't HAVE to end up as unusable garbage, but usually do."
This is also why I've often said software built under government contract sucks and has terrible UI/UX, and why I'm glad I no longer work in that industry.
The moment you separate "customer" from "user", you end up building software for some senior paper-pusher who is just trying to check all the boxes on a requirements checklist. And guess what? "The software shall have a quality user experience" is not something that can be included in said list of requirements.
And in this environment, most developers even think their job is to "build software that satisfies all the requirements" to the point that they're completely oblivious to all those other concerns that would be downright mandatory if the software was sold to the end-user.
The truth is though, if you make user focused B2B software, it likely won't do well.
I worked on a product recently where we built a new stripped down mobile version of our enterprise software that was extremely easy to use for the average user, but had minimal functionality for management. Our manager users have never been big adopters of our mobile software, because they spend most of their time looking at large reports that don't work well on mobile, so we figured this was a safe strategy, at least for the initial launch.
However, we saw extremely low adoption, because managers would try the app, see that the minimal amount of features for them, and then they wouldn't recommend it for the rest of our users. We refocused to adding features for management, and we started to see much larger adoption by the average user.
Selling user focused software to the someone who isn't the main user will always be an uphill battle. The companies that have had the most success are those like Slack that are able to get into the organization without the buyers approval first.
On the other hand, good enterprise software ... Comes with an API that doesn't break on a whim every few weeks, but is stable over years or decades. Works diligently to solve bugs on a timetable. Changes gradually. Has plenty of documentation. Offers training courses. Is certified to work in highly regulated environments.
Nice video. I've definitely heard this narrative before. There was a great blog post on HN a while back bemoaning feature lists but I couldn't find the one I am remembering on google. I found two other on-point articles of interest, though:
While I was at university, they installed a system called It's learning. It gave you basically a forum per class and a way of handing in assignments. It was basic, but broken in many ways (like a rich text editor that only worked on IE - meaning I couldn't actually send messages from my Mac; in 2006), and everyone agreed that the only thing it had over the custom system that came before was looks. I think for a long while part of the old system even had to be embedded, because It's learning didn't provide all the features.
What it did have, though, was a lot of nice videos presenting it. This was extremely high tech at the time, and quite likely to woo the people buying it... maybe they felt they didn't even have to try it, because they'd seen video demos.
AFAIK it's been replaced twice in 15 years. So yeah.
I had the impression, after working in two big corps, often even the "IT people" working there don't know much about IT.
Sure, the people who run their data-centers often know their stuff, but "IT professionals" in their other depts are some business people with some extra IT training.
Often there is at least one person who doesn't know what they are doing, but doesn't say so. Which leads to bad decisions.
One is enough, because all the people who say "they don't know" will go to the ones who don't say it. Then you end up with some a whole bunch of subtle implementation details that are based on wrong decisions, but accumulated to one big mess.
Enterprise software sucks because most companies who build them hardly have product designers. The distance between people who build those softwares and end users is quite a lot and no direct communication is usually possible. Most of the people building these software have zero idea of what the end user stories look like.
My wife, an optometrist, spent many a evenings complaining about the severe lack of usability in the software she had to use everyday. It is so bad that when she quit her job she found another firm which used the same software so that she did not have to go through learning yet another crappy software again.
Products die young or live long enough to become complex "enterprise software" that a subset of its users hate immensely.
I would also like to point out enterprises have unique and complex workflows which require these softwares to have such complexity. I worked for a a big bank and every new manager/director/partner tried to bring in change by introducing more complex workflows and more checks.
So it's not a software problem its a people problem. It starts of as a thing that could be done on a white board and then you end up using complex Service now UI to do the same stuff.
I'm the lead developer in an org where due to the nature of servicing multiple stakeholders that have a lot of say on what we build - we're building these these types of monstrosities where everything is configurable so it takes dozens of clicks to go anywhere and the end user is not a priority.
Yesterday I almost cried. I've started dusting off the old resume, catching up on my craft and I plan to go back as a senior software engineer in a consumer facing project at a remote first organization, wish me luck.
This is very relevant to my current project. We're building a dashboard that's fed with very diverse data, could allow you navigate and examine that data in tons of different ways, and we could make it incredibly configurable.
But we're also aware that our users are not power users. It first needs to be understandable to use it. If we throw a ton of features at them, because they'll drown in them and then not use it. And the prospective users are the decision makers here: we're building this for upper management, and they have no idea that they should want this, so we have to make this attractive, easy and pleasant to use. When they see it, they have to want more, not be put off by incomprehensible complexity.
So we're holding back on features. I know a million features I could add to this, and I really want to, but every time the question becomes: how will they access this? How will they understand what this does? So we're careful in adding features, and put a lot of time into getting the interface right. It doesn't yet have all the features I want it to have, but hopefully all the features it has will be features they understand and want to use. And then we'll add more based on what they need, not on what we think we can offer, because that's going to be way too much.
As a professor, this is completely true about blackboard, and every other LMS (like canvas, etc.).
Making it worse is that some universities have policies forbidding professors from rolling their own system (either for frivolous "security" reasons in the low-trust environment that is the modern university or because of some kind of bizarre ideas about brand identity), so there is no market pressure on any of these companies to actually serve end users. It's horrible.
I worked in this industry with blackboard, making something similar. The truth is that the school administrators hold the purse strings. They also don't actually have very much money to begin with - margins are tighter because your price per user is much lower than most business to business end-user systems.
The users absolutely want features. And you hear about them. Its the joy of the developers working on it to actually deliver it to them. But the admins don't care. They don't want user-level features and ease of use. They want reports. Lots of reports. They want a system that will generate a report on anything, in exactly the format and UX that they desire, ad hoc. And then they want it to be customizable in every way possible. This is where the majority of work goes, because the people with the purse strings demand it. If they demanded a better UX, they'd get it, and the developers working on it would be MUCH happier. We had one of the "better" UX's but it got older, and work couldn't be prioritized onto it.
So really, the parent definitely rings true to me. The incentives from the "buyers" is NEVER about a good UX. Its an afterthought. Maybe if the buyers were more accountable to those having to use it this would change.
"Body Shop" consultancy farmed me out to company producing software for corporations in an industry known for its artificially-inflated profit margins. Additionally, the software itself helps (or at least, was intended to help) the corps with regulatory compliance.
Company's software was horrendous, but they were making millions selling to this industry, and I quickly came to realize they did so by having a 5:1 marketer:software developer ratio, and selling to people making purchase decisions who were very much not spending their own money.
And as a developer who worked on the project for several months, I have no idea what the end-user experience must have been like, but I can guess.
Problems with their app dev process (largely a personal rant):
1. Nested Active Record pattern meant developers could not reason about the performance of the code. Simply referencing some Object.Foo property meant than a virtually unbounded number of out-of-process calls would be sent to the db. Management abhorred the notion of doing anything to improve this.
2. Cloud-based SQL Server hosting was cost prohibitive (customers prohibited multi-tentanting), so mgmt thought they could get their dba to convert the app to Postgres by doing find-and-replace of the SQL strings that were basically interleaved 1:1 with code all throughout the application.
3. Mgmt would get 3-4 people to work on the same code file simultaneously, in a dynamically-typed language and with no unit testing. "Hydra Bug" doesn't even begin to describe ...
And this company was making millions of dollars selling this software.
This is missing the point. End users are clueless about what they need in a software solution. Take a sales pipeline, it's made of sales opportunities. Easy, right? Try to get 50 sales managers across various countries to agree on what a sales pipeline should be and do. I am sure Blackboard has the same issue. Enter consultants. They are not completely useless, they try to get those 50 managers above to agree on 1 idea and process. But depending on how much credibility and trust said consultants have accumulated with the company there is only x% of crap requirements they can say NO to. The x% of crap requirements they have to say YES to from those 50 people for lack of contractual power, credibility and trust is directly correlated to how much the final software solution will suck. And I am assuming the consultants here are good, assume an x multiplier for incompetence.
My point is: there is not enough focus on the business process and people aspect of things. A software solution is packaged consulting and best practices, nothing else. So if nobody is looking at the process and is able to dictate that 1 and 1 only process good luck building something that doesn't suck.
Reminds me of my latest experience with the enterprise video conferencing software that will remain nameless.
One very important thing is knowing that your mic is muted. The button for muting the mic has an icon of a mic with a slash thru it (which in other software would mean your mic is off/muted). No. Not with this wonderful piece of enterprise software. I found out by yelling across the house at one of my kids while I was in a conference call with about 100 folks all over the world. It is the color of the button that tells you whether the mic is muted (aside: I am color blind). Later, after reading the online docs this is what I determined about the color of the button:
* blackish => not being used (?)
* red => used but currently muted
* blue => used and on
* clear => someone else muted you!
If you have to read docs to figure this out then the software is already a failure.
Also having a slash thru the mic should definitely imply the mic is off if they did any usability testing!
Also, the mic is on by default! Also, I noticed my video camera was on as well by seeing the little orange light at the top of the screen!!
A bit of insight into the complexities of designing enterprise software—I'm a product designer who's been fortunate enough to work on a fast growing product. When I joined our average number of seats was probably about 20. I'd imagine it's now 10x that.
As the post mentions the buyer is not always the end-user and in the enterprise space features are often prioritized for the buyer. That's not necessarily a bad thing, but enterprise product teams should watch out for buyer-focused features that deteriorate the end-user's experience. We spend a lot of time thinking about how to avoid that.
There is also a trade-off between simplicity and flexibility. It is often impossible to do both and larger customers will always want flexibility.
Designing for multi-level hierarchies within organizations is also exceptionally difficult—visibility, access controls, permissions, groups, group hierarchies—these have all been the most difficult features I've ever worked on.
I have immense respect for the product teams at Salesforce, Microsoft, SAP and the other enterprise software companies. The stuff is not easy.
The real reason is that different businesses have different needs. No one company knows all these needs in the beginning, so they build and keep tacking on to their existing solution. They can't easily refactor and break UI changes for their existing clients, so it's end up a big ol mess of everything.
Given everything most enterprise companies know, they can design cleaner simpler software, but the reality is there's no time to stop when you have a business to run for the big ol design. When that is done most of their customers are pretty unhappy, something as simple as changing UI change can be very expensive for your clients, they might have to retrain thousands or tens of thousands of their users. Something as simple as an upgrade, if not a zero time upgrade can affect tens of thousands of users. Enterprise is not as stupid as folks make it out to be. There's a reason they got to being enterprise and make a lot of money, they are a different kind of smart.
Ok, so this has been locked in as one of the top posts on the front page for a day or two now. I'm sure there is a good reason. Maybe it's an interesting topic, or a lot of people agree with the particular message.
But can we talk about Twitter "essays", as I like to call them, for a minute?
As soon as I see someone chaining together 3-4-5+ (let alone) 10 tweets in a row, I immediately check out & hit the back button. That's not what Twitter is for.
It has a short character limit for a reason. It's meant for SMALL, quick thoughts. Things I can scroll through quickly, consume, and move on to the next bit in my feed. Not long, drawn out opinion pieces.
If you have that much to say, write a blog post about it. Write a post in a relevant sub-reddit. Send an OP-ed piece to your local newspaper for all I care. ANYTHING, buy try to make me follow your meandering, 10+ tweet long, stream of consciousness.
I admit I didn't read past the second tweet in the chain. I read enough to learn this twitter 'essay' was spurred by his college droping blackboard. I remember blackboard in college. It's was pretty mediocre but served it's purpose for it's time & place.
Anyway... I get the reason people do this. It's typically people with a lot of followers (like this guy, with 50 thousand) and they know this is the platform that will get the most reaction for whatever undeveloped, spur of the moment, rant they want to spew out.
Which is my point. Twitter is for undeveloped, spur of the moment rants. And if it spans more than two tweets, then tweeet us a link to your blog post. Or else don't get mad when I get distracted by comments in the third tweet, and go down a rabbit hole of shit talk before I make it to the end.
Well, sorry for the HN comments rant here. I got a little to angry I guess, but at least this is a place where long form comments are acceptable. Twitter is not.
Yeah you're right. It's just been driving me crazy for a while now.
It just feels so clunky. It feels very self-gratifying.
Part of my point is you typically only see this from folks who have a large amount of followers. Of which, a good percentage would be happy to click on a link to writing from someone they're ibterested in.
Seems like they are doing it because they enjoy the reaction from their follower base on the platform.
Don't make us try to follow a 1000 word thesis, in disjointed, 240 character increments... which might all have their own chain of comments.
Let us read the whole argument uninterrupted, & comment @ the end together. I'm only saying the platform isn't suited for long form ideas & discussion.
Again, sorry for ranting. Maybe I'm just in a mood tonight haha.
"Here’s the kicker, though. It's extremely likely that whichever vendor emerges on top will fall into the same trap. The incentives almost guarantee it."
Why do all bug trackers start out as "simpler than $TODAY'S_DOMINANT_BUG_TRACKER", only to become the thing that tomorrow's bug tracker is simpler than? Why do programming languages almost all start as a "simple alternative to $X", only to be the thing that needs a simpler alternative in 10 years? Why are there so many UNIX shells that start as "simple alternatives" but then grow too large? Why are there so many libraries and frameworks that started out as "lightweight" but grew into monsters?
Because the problem is in the incentive structure of the problem space, not the terrible programmers who just couldn't resist adding so much complexity.
All stated reasons are valid, however in the software industry, IMHO, the #1 reason is because in many companies, if not most, the people writing the code are not the people making decisions. It's also easy to see that it's the most successful ones that are lead largely by advanced technical people. From my experience it seems there is always a tension between how highly technical people and the business people make decisions. In some cases this gap is a chasm, and the miscommunication across the technical skill gap is so bad there is a lot of wasted time, effort and money, building horrible software and prioritizing the wrong things. And even when a balance is attained, it either doesn't last long or it makes huge compromises in productivity (basically everyone is happy condoning bad software).
I was surprised to not find a single instance of "fear" or "accountability" in all the comments. The major driving force in "Big Enterprise" is putting a price tag on "are you prepared for something to go wrong." Either with bad actors, stupid mistakes, or lack of resources. The overhead and settings required to increase or decrease how much exposure the customer is willing to take is what drives the indu$try. That being said, I don't disagree with a lot of the comments. There is definitely the case of over engineering, but that is a bi-product of a business having to decide between making money or turning away a customer. Great companies have kept it simple while steered their users toward simplicity (which drives down cost and errors for all parties).
One thing I'm not following is a few remarks that they don't do usability testing because it is subjective and thus a lawsuit magnet.
We're talking about universities that, as part of their mission, have psychology departments run studies that must conform to ethical guidelines.
Couldn't they evaluate the usability of candidate products by coming up with a list of tasks that a small sample of students and professors must complete, and rate how difficult they are? Take the mean weighted by how critical the features are there's a reasonably objective usability score.
There's still a subjective element, but it can be mitigated by selecting participants at random and having them disclose any potential conflict of interest.
I realize this is no small undertaking, but it's part of their core operational model, so it doesn't seem unrealistic.
> Other baby outfits are meant for parents. They’re marked "Easy On, Easy Off" or some such, and they really mean it. Zippers aren't easy enough so they fasten using MAGNETS. A busy parent (i.e. a parent) can change an outfit in 5 seconds, one handed, before rushing to work.
Magnets? That sounds like a terrible idea, since babies are not supposed to be around little magnets that they could swallow (and after a few times through the washer/dryer, magnets could come loose.
Is this really a thing? I have two kids (and one baby, so we're in the thick of it), and I've never heard of this. More importantly, we wouldn't think of buying anything for a baby that has little magnets sewn into cloth.
It's the histrionic piety that's the problem, not the particulars of the facts. It's in the context of watching parents killing themselves to prove to other parents how their children are their sole focus in life, and that anyone who would do less is an unworthy parent.
It's evident in an argument of the form "we wouldn't think of X," wherein compromise is simply declared out of bounds of any possible discussion.
Prior generations of parents did not do this; they struck a balance between their children's needs and their own needs. That's why there are new terms to describe the modern excess: helicopter parenting and even "snowplow" parenting[1]. These are not healthy developments for parents, children or society as a whole.
Well, the good news is that you've completely misunderstood my comment. There's no histrionics, nor piety. I don't care what other people do for their kids (I said this elsewhere in the thread), and I can imagine that other people, especially people with disabilities, might find the magnets to a useful option. But for me, zippers are easy and work just fine. Therefore there's no need to take even a small risk to replace something that works just fine.
Another consideration is the flood of cheap counterfeits on Amazon (commingled at times), which means that you can't actually trust that the item you purchase is the genuine article (i.e., that it's as well-built as the descriptions say). So
I'm not sure what snowplow/helicopter parenting has to do with any of this, but I'm right there with you that people do too much of that.
If anyone out there decides not to have kids because I don't buy baby clothes with magnets, I think they care too much about what other people do (with their own babies).
Magnetic closures are usually enclosed in seams, and address a very real need (ease of one-handed or even two/three-fingered operation). Zippers are an actual hazard for baby skin and also tend to take more hands to reliably do/undo than the typical parent trying to manage a screaming, possibly wet baby (or babies!) has available. Even if you're sticking with more traditional fasteners, snaps and Velcro are way more sensible options.
Interesting perspective, thanks for sharing! We find zippers to be great, especially the ones that start at the feet. Never found them to be a hazard for skin, through thousands of openings and closings. Also, snaps are definitely the least sensible option for us, since there are so many of them on each outfit. We never buy those, and the ones we've received are used much less than the zippered ones. Glad you've found something that works for you and your baby.
Honestly one of the factors leading to my burnout and depression was being required to be 'the face of' and promote the use of a piece of enterprise software that just confounded your expectations as a user at every turn.
I tried my best, I went to conferences and met the woman charged with modernising the UI and submitted the extensive feedback she asked for. She left the company 3 months later.
Training sessions were a constant flow of 'yeah that is a bit weird, but that's how it works!'.
I submitted via the vendor's service portal enhancement requests for everything that came up. Two years later they were all closed.
I knew it was hopeless, but I had to try. I wish I'd just refused and found somewhere else to work.
This is also why training often sucks: the teachers write the presentation not for the people sitting in the class (who are often required to attend), but for the people who run the training office or the supervisors who order the training.
> "OK, back to Blackboard! It’s actually designed to look extremely attractive to the administrators (not professors and definitely not students) who make purchase decisions. Since they can't easily test usability, they instead make comparisons based on… checklists of features.
️"
Former Blackboarder here with +50 implementations in 4 years.
Blackboard and its main competitors -- specially the best ones -- are extremely focused on building atractive UX to instructors because that is where you find most of the critical success factors for a good implementation and ongoing operations. If you have a well thought implementation and operational model, work for administrators can be reduced to a minimum, specially if they have purchased the "managed hosting" pack.
Back to instructors, they are the ones who need to adopt the platform in the first place and then either conform to the type of online course they will be delivering -- in case it is a cookie cutter model -- or be trained and prepared to create and maintain their own courses. Some institutions still opt for a blended model in which professors have more or less liberty to shape the course to their needs, and that would depend mostly on the program structure.
So what the student ultimately sees and uses is the resulting product of a lot of people working behind the scenes. It's hard to generalize and blame Bb, or admins, or even instructors. Blackboard offers a full set of services for "Adoption", and they are delivered by EDU consultants who know very little about Blackboard Learn, the LMS. They know about EDU processes, student motivation and online learning approaches that are LMS agnostic. With that, instructors could be taking a leading role in driving student UX experience through the platform and learning objects it delivers.
IMHO, enterprise software sucks (to everyone) because it is really large, complex and depends on the dedication of an army of people with different skills and viewpoints. Well, that's the glass half empty. You can also say enterprise software is the coolest thing because it exercises and uses the very best of us all the time, a real tech challenge. That's the glass half full.
I know a number of college professors. Of the ones who have had to use Blackboard (always imposed from above; they are not being given a choice about adopting it), I have yet to meet one who likes it. They definitely do not perceive its UX as attractive in any way...
Enterprise software doesn't have to suck. I worked on databases for oil & gas and similar systems and even though the UI wasn't the best, it was an off the shelf solution that many customers could use their complex problems and regulatory needs. If ease of use is your only metric of quality then lots of Enterprise software sucks, but if you measure quality by how effectively it solves a problem for a customer, Enterprise software might not look so bad. Also blackboard might suck (as a student it didn't strike me as horrible), but there are good tools in the same industry like Piazza.
Partially because enterprises are hiring el-cheapo hit-n-run development contractors via Tatas and alikes and all along this middlemen-infested food chain no one really cares about the product, users and customers.
Companies buy it because of sales, support, and the warrantee (the ability to hold an “enterprise” with financial resources accountable for mistakes).
Importantly, because large companies use complicated, slow decision making processes with many people involved it is very expensive for them to buy software AND it is extremely expensive to sell them software. Vendors of “enterprise” software can support all the meetings and risk all the expense of that sales process.
The feature checklist exists to provide rationale for the purchasing decision, but it isn’t essential to the decision.
For my senior project, they had us prototype a replacement for Blackboard. This was not just an exercise: the CS department was seriously considering building and maintaining their own alternative.
They already had a custom web interface for submitting and testing code. It was... very HTML 1.0, but at least it wasn't actively user-hostile like Blackboard.
Loved this thread but none of this is new. I dont know anyone that likes SAP, Netsuite, Etc. But that doesnt matter. Big companies make decisions to minimize risk and stay on the right side of the law and compliance issues. If the user(s) are miserable and wasting tons of time, no one cares because the company is protected.
I am interested to see if today's new productivity apps (Notion, Trello, Slack) end up in the same vortex of hell as the enterprise tempts them more and more.
A regular larger enterprise probably have at least 500 individual software systems, that have evolved over 30 or more years. Around this you have several tens of thousands of employees. This landscape can be compared with an extremely complex machine, or possibly with an organism having equally many organs as there are systems. It is no surprise it sucks because this can never work without constant manual intervention to fix what breaks and does not work as expected.
I think one person choosing and others using (and/or maintaining) software is a part of the reason, but another part is that "enterprise software" is essentially a single software package used by multiple users, usually incompatible with standard and open protocols/formats: even when the person choosing it is happy to (and does) use it, it still can be (and often is, IME) awful for others, due to differences in preferences and requirements.
Nothing gets developers as excited as having hour long meetings to learn "the correct way" to log a ticket ! O joy the workplace is set for innovation now ! FML
Let's take this a step further. Why are the feature checklists used? Because the schools are mandated to pick the lowest bidder through an RFP process. Not the best value, not the most usable, just the lowest bidder. The checklists were introduced as a metric to avoid wasting software that wouldn't meet the users needs, but for years ed-tech companies have optimized for meeting the checklist in the cheapest bottom-of-the-barrel way possible.
I spent a few years doing indie game development, and one of this biggest lessons that stuck with me was how to think about a product as an experience. To me, game design was mostly that, but focused on making the experience fun, I guess. A huge amount of time and effort went into thinking about what the end user's experience would be like. By instinct, I tend to lean on thinking about the "player's" experience.
Enterprise software sucks because the people who develop it do not understand the underlying business processes they are trying to support, and business people who understand the processes do not understand how software can interact with that process.
This leads to things like software being bent to support an existing (shitty) process, rather then redesigning the business process to effectively integrate software effectively to automate the process.
* Everything is a "workflow" and you often find yourself stuck in some terminal error state for no reason.
* No JSON, everything's a page load.
* ...or, if there is JSON, it's done badly and you have an unholy combination of janky SPA functionality across multiple pages.
* Arcane timeouts
* "Disable your popup blocker"
* Insane data validation errors.
* Poor SSO integration.
I think the main point is simple economics. Software is all fixed costs, the costs of making a copy are zero.
So let's say you are making enterprise software, if your market is 1000 companies, you will sell at most 1000 copies. If you charge $100,000 per copy, you will generate at most $100 million if you capture 100% of the market. That's the world of enterprise software.
If you are making consumer software, your target audience is 3 Billion. If you charge $10 and capture the whole market, you will make $30 Billion.
What that means is that compared to consumer software, enterprise software is incredibly expensive while also having 1/300th of the development budget to build the product.
Corollary 1: Enterprise software will never win head to head versus consumer software, and firms will use consumer software whenever possible.
Corollary 2: Given the small dev budgets, Enterprise software will skimp on all non-necessary aspects of development to meet the minimum viable product standards before they can ship. This is why your corporate accounting software package has a terrible UI but it has the required functionality and uptime.
Corollary 3: while consumer software often can fix bugs and roll out patches on a monthly basis for free, enterprise software will fix bugs with delays in years and only with expensive support contracts.
Corollary 4: Enterprise software is both highly customized and highly rigid. Highly customized in that a lot of Enterprise software development is bespoke for a few key customers because of Corollary 1, and highly rigid in that Corollary 3 means you are stuck with whatever they deliver.
I remember for a while, Cisco had a branch for each major customer. Imagine maintaining hundreds of branches in your code base.
Once you understand the basic economics of the thing, you no longer have to ascribe ill will, incompetence, or ignorance to any actor. It's just "you get what you pay for" and "no one can do miracles" in a product which is all fixed cost.
With those broad facts in mind, most aspects of enterprise software become obvious. I really don't think issues like "someone else buys it, not the user" make much difference. After all, parents buy lots of consumer software for their kids (games) which are amazing and incredibly polished.
This post seems to blame the administrators for picking a product based on checklist. The problem is if the administrator is concerned about his end user, he would consult his end users who will end up giving him a checklist of features which would still be a problem.
This missing piece is discussions on user experience, which for enterprise software, would need to be done on a case by case basis.
Because Blackboard was used as example, I just wanted to note that there are also open-source alternatives: A larger number of German public universities use ILIAS instead https://www.ilias.de/en/. While it has its quirks, I find it to be much more usable and flexible than Blackboard
You'd think publicly funded schools would have a system-wide public software infrastructure project instead of just writing a check to Blackboard every year to infinity.
I always wondered why full time academic-oriented OSS activists like RMS didn't campaign for things like this instead of trying to sell the concept of "OSS in General"
This existed much more in the old world of legacy software and perpetual licences but is bad business in a SaaS model.
You end up in a situation where higher ups notice they’re not getting the best use out of it so the customer ends up churning. Happy customers with happy end users end up buying more of your software and are much more profitable.
This is right on. Enterprise software sucks because the entity paying for it is not the entity using it.
The same issue is one of the factors that causes health care in the US to be so maddening. US health care is essentially enterprise medicine. Patients receive it but insurance companies pay for it, and the two agendas are not aligned.
A lot of enterprise software isn't even sold to the people who will actually end up using it (users OR admins). It's some VP talking to another VP agreeing on terms/pricing for "good enough/checklist" and "implementation" costs so it will look good on their yearly review.
What's wrong about this is only that users like features too. I.e. he's exactly right that the features checklist leads enterprise software selection processes astray. But I've participated in lots of them that have real users in the room and even then, the features checklist wins.
End users should use UX user interface first principle and code an open source alternative thats better. Ie gather enough frustrated end users and create something better.
Tools like Moqups or Balsamiq to create user interface prototypes by designers.Then open source is created from these prototypes.
At my university, I think they used to use blackboard, but we have since migrated to a homegrown solution, partially built by students. Some professors also use Instructure. I think the consensus among the students is, however, the homegrown solution is better.
I think best solution will be, just like every business have accountant, every business will have software designer and a easy to use software that can do whatever it was asked to do, a cloud based software, with complexity and skill of excel is enough.
As an aside - the author of the post is Princeton professor Arvind Narayanan. I took his free Cryptocurrency course on Coursera and it was superb. He really broke down all of the concepts in an easy to understand way that has stuck with me for years.
I think it's also economics. The person who is making the purchase decision is different from the user. Hence, a lot of efforts are spent on courting the purchaser compared to improving the product for the users.
I am a SAP ABAP developer and it was my pleasure to debug a PO Badi the other day ... sigh ... looking at the mess of of their code I was just amazed that it was still running in 2019.
This is changing though. A fair number of solutions such as Slack are easy enough to use and get a hold of that teams within large enterprises can simply start using them.
The problem that companies like Slack face in making inroads in enterprise is that companies like Microsoft dominate the market, and can offer entire suites of products at a discount to keep customers exclusive to their platform.
Microsoft has it’s own internal chat tool (which is terrible), but this strategy keeps their clients locked in while the buyers stay happy
Pretty much this. We had a stint on Slack in our enterprise. We kept asking for full licensing for it, but the higher ups moved everyone to Microsoft Teams instead. It's not lacking against slack in any way. It really just comes down to if you like the UX, which I don't like for either Slack or Teams.
Except MS Teams suuuuucks compared to Slack. The interface just isn't intuitive and you can't just use it. The number of times I miss things because I didn't realize my input was needed, or I'm still getting notified on threads that only needed a single comment from me way back at the start of the conversation that I no longer need to be a part of is ridiculous. My tools should get out of the way and let me do my job. Unfortunately, most enterprise tools quite clearly stand between me and my objectives and they're frustrating AF.
It's 2019, our software should have gotten to a point where the computer is working for us, not the other way around for God sake. Nobody should still be working a job where their entire purpose is to make the computer do what you need it to. No wonder so many people feel like they've lost their sense of purpose.
Simple consumer friendly products have a tendency to get more and more complicated as they try to expand their market into the enterprise. The question is not whether Slack is simple now, but whether it will still be simple in 3-5 years.
Of course, Slack already isn't that simple. The authentication model seems insane, and no one can ever explain it to me when I ask.
It's nice that me@gmail.com and me@corporate.com can be logged into different slacks in the same electron app, but why do I have different accounts/passwords for me@gmail.com for different slacks? It's all the pain of federation without any clear benefits.
When I was in academia the faculty were on the committees that made such decisions, especially those regarding ed tech. I guess Princeton is a different story.
1. baby outfits marketed to people who cannot admit to themselves that they are poor.
2. baby outfits marketed to people who aren't poor.
The author is making a division between two types of outfits in the first category. The second category has no such division-- those consumers have enough money to pay for a product that looks good on the rack and is ergonomic.
In my opinion it sucks, because people, who write it screw up even the most simple things. In a lot of such software, you will get a search field for something. Rarely the search field will work as you expect. Here are three examples (beware, rant starting):
1. Windows search: It will sometimes not find what you are looking for, because it is not able to at least do a "string contains" check, if there are no other results found. How stupid is that? Glad I don't have to use Windows unless I am trying to solve a problem for someone who uses Windows.
2. Confluence wiki: Nope, sometimes you will simply not find that page, with some word in the title, which you input into the search field. Too stupid a software, to simple check for string contains. Oh and also sometimes your search does not work at all, because some service of Atlassian is offline.
3. Friend of mine did some work for an insurance company. They had a software to look up customers. You think you could easily find someone by looking for their first or last name? Nope, he had to enter an additional space after the first name, to be able to find the person, which of course was confusing.
So, I as a single person have coded in some projects search fields for applications, but some huge company with dozens or more developers cannot get a simple search field right, while I as a single person can write a search, that allows incremental searching and is functionally complete with "not", "or" and "and" operations on objects. Somehow I doubt the capabilities of the engineers, who wrote the logic for those search fields in the examples I mentioned.
There is also other things wrong with Confluence Wiki:
A while ago they claimed to now support Markdown in their editor. Well, it was a not even half-assed support of Markdown, as most of the things I tried to type in Markdown did not convert to the respective rendered elements. To this day, the editor they have just sucks at Markdown and at times behaves unpredictably. I despise having to put anything in the wiki, because of it's buggyness, sluggishness and bad support for Markdown. How difficult can it be to give me a simple editor and let me type Markdown or another sensible format?
My personal blog has a better Markdown parser, than Confluence Wiki and I did not even have to write it myself.
My self-written wiki uses reStructuredText files for pages, simply put in a directory tree, which gets me document internal linking and cross references to other pages of the wiki and the ability to simply put the wiki into a git repository and have everything version controlled. Oh btw. version control is also F*ed up in Confluence Wiki. Also I can simply "export" any page, by copying its file, while in Confluence Wiki, you cannot even get a proper export of a page. This is of course intentional, to keep customers stuck in their Wiki. No way, that they provide simple means of migrating away. No, better to hold the user captive in their BS software.
I have to agree with some other comment here, which mentioned, that the problem is, that the buyers are not the users. I would happily give my own wiki implementation to people at the job, but people, who make the decision on what is used think, that Confluence Wiki will be better than anything a single person can come up with.
It took me three seconds to find those by Googling "Why enterprise software sucks". I worked in enterprise software for a decade, and I've heard a thousand versions of this.
It's easy to complain about stuff. It's even easier to repeat complaints that have been made hundreds of times already. It's hard to find solutions. This guy doesn't deserve any credit for reiterating old complaints without any hint of how to fix the stuff he's complaining about.
There was a big push for us to use it for student assessment.
I tried, I honestly did.
1. I used it to set homework assignments.
2. .py files were blocked and students couldn't upload them.
3. They submitted code as .txt instead.
4. I'd click on my class to view submissions, it showed the top 5 submissions.
5. I'd click on a submission and it would download.
6. I'd view the submission locally.
7. I'd convert to .py to test the code worked.
8. I'd assign a grade.
9. I'd then have to click (maybe 5 - 10 times) through to a different page to record the grade.
10. I'd then have to go back to the submissions page.
11. After grading the first 5 submissions, I'd click through to the next page.
12. After grading the 6th submission, I would be returned to the first submission page and have to click forward again.
13. When you get to the 30th submission, you're maybe doing fifty clicks for each homework assignment.
14. I had 4 classes all doing the same assignment.
15. This could not be amalgamated into a single marking spree.
I spent weeks trying to grade my students and then just gave up and had them email me their assignments from that point on.
These platforms are all full of features; commissioned, designed, tested and developed by people who have never set foot in a classroom.