Why Enterprise Software Sucks
twitter.com
twitter.com
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.
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.
It should be - but for many school IT security types it really is a feature to limit file types
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!
What about security patterns for web browsing?
I feel the logic is somewhat similar but injections to websites / applications may be easier and hard to prevent against, so filtering pornography may be useful. I’m a dev not a security expert so sorry in the lack of understanding. I am actually trying to learn more about security / hacking
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.
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.
why is the vendor that makes the OS (MS) making these types of decisions?
Recent-ish (past year) Gmail patched this (for .tar at least), so I started using base64 encoded text files.
Now though I just pay for my own email service away from Google.
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).
I'd expect a site/application that is designed for students to manage homework would have different date/timestamp requirements.
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.
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.
<time datetime="2019-10-11T13:53:36.861" title="Fri Oct 11 2019 13:53:36 GMT-0700">2 minutes ago</time>
On the website I'm looking at Google Analytics for right now, fewer than 35% of the visitors are from devices where "hover" means anything...
Sadly, what you describe as the anti-pattern is actually the industry standard.
And you don't have to go far to see examples — Slashdot and Reddit redesign come to mind. Both are unusable.
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.
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.
You can't believe people aren't aware that concur is a pita and hence it reduces expense valid expense submission...
That's not a bug for some companies, who would prefer to not reimburse you.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Put another way, that Bob thinks he's dealing with "big data" doesn't mean he is in fact.
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.
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.
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.
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...
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.
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.
- 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.
In any event, it should be able to fail gracefully ie still load the sheet but not be able to calculate cells using new features and show a warning.
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.
Bingo—the dysfunction of the software reflects the dysfunction of the organization.
Melissa Perri calls it the Build Trap: https://www.mindtheproduct.com/escaping-build-trap-melissa-p...
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".
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).
ImageMagick and Photoshop serve completely different needs. You can't replace one with the other.
Yeah but that's not because of the software itself.
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.
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)
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.
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.
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 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.
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 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.
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 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.
https://helpx.adobe.com/content/dam/help/en/photoshop/using/...
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.
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.
Please explain to me how you imagine creating a mask around a human so that you can "extract" him from the background in the command line.
You can select a group of operations you did in your editing history and turn them into an Action, with parametrization support.
You can then batch apply an Action to a bunch of files.
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.
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.
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.
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.
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
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.
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 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.
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.
Some friendly fyi of MS history...
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.
The shift was in computers, from enterprise to consumer, and the software followed.
A Dell all-in-one (not especially budget), is £580 [2]. A bulk buy for enterprise would be cheaper. This is inclusive of the cost of MS Windows OS.
In the UK a computer that can run MS Office decently costs around the price of the software.
You can see why MS create a new version every few years; but why do offices keep buying it.
[1] - https://products.office.com/en-gb/buy/office [2] - https://deals.dell.com/en-uk/productdetail/2sue
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.
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.
(with the separation of concerns not really mattering in the usage of the tools)
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.
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.
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
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?
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.
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.
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.
I agree about SAP and JIRA, but the other ones are IMO universally loved.
I've never found a designer complaining about Photoshop which is the holy grail for bitmap work.
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.
If enterprises were selecting for this then you would expect emacs to be the most used enterprise software of all time. :-P
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)
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. :)
- 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.
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.
This sounds a lot like Android's "activities" concept which doesn't get enough love, in my opinion.
but what if the overall model/structure is really what sucks?
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.
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.
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.
'Custom' is scary in a way that 'customizable' isn't.
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).
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.
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.
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.
And scaling beyond 2-3 real customers does make a very big difference for any legitimately good company.
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 was arguably Steve Jobs key role at Apple.
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.
https://sixsigmadsi.com/grandmas-ham-a-story-of-cultural-tra...
perhaps the ends were being cut off because they often rotted near-invisibly faster, and now you've gone and poisoned the whole family :-)
Companies only use 5% of the features the more sophisticated enterprise software is offering but it's a different 5% each of them use.
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.
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).
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.
... which adds features to the product as a whole, which other customers will need to be aware of and might take advantage of.
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.
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.
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.
I would lay money that far more security vulnerabilities are due to overcomplicated customizability features than are due to simplified UX.
That was an uncomfortable day. ;)
Once you cross a time zone, your records are much harder to access.
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.
I kinda like the idea of regular scheduled downtimes of stable systems, just for real experience on downtime procedures.
Sure people could use notepad, onenote, powerpoint, other proprietary software, but they are comfortable in the grid like ridgularity of excel.
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.
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.
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.
It's just plain hard.
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.
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.
iPhones and smartphones in general have greatly increased the risk of data theft or being spied.
Insurance companies are more than happy that others have switched to smartphones (I worked in insurance consulting for cyber risks)
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.
My partner worked here - https://en.wikipedia.org/wiki/LafargeHolcim
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
I'm assuming your employer has never heard of printers or copy-paste. ;)
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.
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".
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 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.
- 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.
Almost seems like "micro-tasks" at this point.
Micro tasks are good.
(And many companies are using MDM along with the iPhone, so it's not like they don't think they need control there.)
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.
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.
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 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.
They do lots of other things a lot better, but email? Nope.
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.
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.
I'd still prefer a physical keyboard, though.
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.
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.
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.
Other than that, what specifically did it enable that the other phones didn't?
But, that's just me speculating...
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.
Source: used to run a BES server
With ActiveSync, my email will usually reach my phone/cellular watch/iPad before it reaches my computer.
https://www.schneier.com/blog/archives/2008/05/blackberry_gi...
https://www.engadget.com/2016/04/18/blackberry-ceo-wont-say-...
That's maybe another way of showing that UX is not the winning differentiator in enterprise that it is in consumer.
> This reads like someone who lives in the valley and thinks the valley is in any way reflective of corporate America.
I don't live in that valley, and I fully know that it doesn't reflect the rest of US or world, and that is why, indeed, enterprise UX does suck! :)
I think we agree... I'm not hearing an argument from you that it's because of superior UX that people are sticking to O365.
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.
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.
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.
Skype for business is an abomination, it’s morally wrong, it’s an evil that must die.
I’m hoping Zoom can murder it viciously.
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.
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.
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)
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.
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.
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.
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.
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.)
Whether or not you choose to respect those needs, they very much still exist for all larger publicly traded companies.
The problem is that's not a continuous function. Leave out specific features and you lose entire industries.
Incentives are not aligned for enterprise software authors to lose entire industries.
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).
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.
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)
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?
I strongly doubt that support for complex and unique workflows is why Blackboard is so bad at entirely conventional workflows.
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?
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.
For instance Slack is great IMO, but they only introduced bring-your-own-key earlier this year (a requirement for security-serious companies).
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.
OP conflating them with enterprise software is not the best premise.
We're working on a process to help the buyer make the best decision - Vetd
Marketing Site: https://vetd.com
Platform Signup: https://app.vetd.com/signup/buyer
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.
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.
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.
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.
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.
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.
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.
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.
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.
Good UX drives costs down for training and draining of human capital. That should be the pitch.
Next question, who in the fortune 100 should hear that pitch?
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.
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!
See also "bikeshedding".
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.
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.
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.
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.
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.
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.
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.
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].
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.
As much as I loved simpler Nokia handsets, N-Gage is not what I would consider an innovation.
A personal opinion, of course.
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.
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.
The result was huge margins for IBM and customers scratching their heads afterwards.
Not so great as an actual business.
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.
Do you consider the G Suite to be enterprise software?
— Joel Spolsky, In Defense of Not-Invented-Here Syndrome, 2001: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
If you're FedEx, you don't buy someone else's logistics software package, you build your own.
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.
-it's very hard to sell
-usually it's crap
-maintenance is expensive
-many use it just to keep their job
-many furtively use better products from young startups
> 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.
> [0]: https://www.joelonsoftware.com/2002/05/06/five-worlds/
And these worlds change over time:
> 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.
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.
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.
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.
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.
EDIT: A little embarassing, but I found an attempt I did at redesigning that timesheet software from 2014. https://dribbble.com/shots/1501268-Webvantage-Timesheet
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.
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.
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...)
If the reduced cost is of making gratuitious changes to a system's appearance or interface ... you'll end up with a bunch of gratuitious UI changes.
Granted any product with lots of customization can do that, but CRM products really seem to lead the pack in terms of huge clusters of OMG.
I kind of do something like that.
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.
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.
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.
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.
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"
The more I poked around this repo, the more funny stuff I found. Thank you, this was really enjoyable.
And the package name is perfect.
1) The guy who says "There's no way a real product could ever be this bad."
2) The gray-beard who responds, "You've clearly never worked on an enterprise Java product."
I have to say that I've seen real code that had constants with a suspiciously similar naming convention, which I guess is the genius of that repo :-)
This is fantastic.
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"
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.
Citationsy (https://citationsy.com) is still independent of course :-)
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.
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.
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.
(See: https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...)
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.
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.
They aren’t being clueless at all. Companies care about their customers - the people paying - not the users.
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.
https://www.cmswire.com/information-management/everything-yo...
https://werd.io/2016/stop-writing-specs-start-finding-needs-...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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!!
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.
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.
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.
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.
I think that's reversed. They gathered a following by posting this way.
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.
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.
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.
This attitude is insane and why so many people refuse to have kids.
Also, zippers take 3 seconds to do...if you don’t have 3 seconds to zip up the kid, you probably don’t have time to change the diaper underneath...
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.
[1]: https://www.fatherly.com/love-money/what-caused-the-college-...
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).
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.
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.
It's unsettling the way you're willing to come right out and admit that.
I have seen too many people in it NOT clicking this huge waste of space away but instead always scrolling down before doing anything.
User don't care that much apparently.
https://en.wikipedia.org/wiki/Banner_blindness
Also, “In fact, users don’t read anything.”:
https://www.joelonsoftware.com/2000/04/26/designing-for-peop...
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.
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.
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.
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.
Hear hear!
I often put it this way: Enterprise software is sold by having the CIO/CEO playing a round of golf with the sales person.
The CIO/CEO never have to use the software. They have assistants extracting the relevant figures etc.
(For context: I interpret "administrators" not as sysadmin but administrative staff)
I could go on.
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.
"a long article"
"as a series"
"of tweets"
"sucks. And why it"
"is better to"
"just post a link to"
"a blog article, or"
"medium article."
"hell even a"
"sorry swap those last"
"two before these"
"three around"
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"
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.
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.
Tools like Moqups or Balsamiq to create user interface prototypes by designers.Then open source is created from these prototypes.
Maybe they are disguised as a start up and hate the label, but what enterprise software companies are taking the right approach?
BaseCamp? Slack?
It would never succeed out in the real world.
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.
Microsoft has it’s own internal chat tool (which is terrible), but this strategy keeps their clients locked in while the buyers stay happy
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.
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.
Sorry.
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.
https://signalvnoise.com/posts/669-why-enterprise-software-s...
https://medium.com/@jeffbrydon/why-most-enterprise-software-...
https://www.reddit.com/r/programming/comments/1v9y55/do_you_...
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.