451–460 of 570 posts
Earlier quoted context omitted.
The compelling feature of gsuite for my employer was apparently the ability to turn off IMAP etc and therefore rule out emails being kept locally/beyond the retention period for better access control/cheaper legal compliance, not anything UX related.
That's... Kind of hilarious. I'm assuming your employer has never heard of printers or copy-paste. ;)
Earlier quoted context omitted.
> Except I can count on one hand the number of fortune 500 enterprises that moved to gsuite over o365. 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…
> That's maybe another way of showing that UX is not the winning differentiator in enterprise that it is in consumer. But it is. That and useful features. Both of which Office has, and GSuite has not. I don't remember the name of that "Word lite" program that was included with Windows for free around Vista/7, which could open less sophisticated .doc files and was a default binding for .rtf files. But compared to Micr…
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.
I write enterprise software for fortune 100 companies. If I put myself in the user’s shoes and had an alternative, I’d most likely uninstall what we built and jump ship. But they can’t. It’s an internal app and the user is forced to use it. I try and fight for what’s right but if I had a dollar everytime I heard “ we aren’t google/amazon” , “only xx people will use it”, “we are just doing this to get off the old tech…
> UX isn’t valued Good UX drives costs down for training and draining of human capital. That should be the pitch. Next question, who in the fortune 100 should hear that pitch?
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.
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.
Earlier quoted context omitted.
I work in a corporate environment and I also write software -- both external and internal tools. My intolerance to unnecessary pain is one of the main driving forces in creating software-based tools. The amount of pain inflicted on employees by enterprise solutions of various kinds is immeasurable. As a developer, I squirm witnessing so much unnecessary work and discomfort associated with simple tasks. For example, e…
I agree with everything you say, except the last bit. You can't believe people aren't aware that concur is a pita and hence it reduces expense valid expense submission...
Earlier quoted context omitted.
> UX isn’t valued Good UX drives costs down for training and draining of human capital. That should be the pitch. Next question, who in the fortune 100 should hear that pitch?
You're assuming that the cost of human capital actually matters in big corporations. As someone who has worked for several Fortune 100s and a couple of government agencies, I assure you, that is not the case. Employee time is treated as having no value, and things that damage the efficiency of employees are not relevant. I once saw a "cost saving" round prohibit our team's QA engineer from getting a new SoapUI licens…
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.
Earlier quoted context omitted.
I’ve never had any trouble with typing on a touch screen just as fast as my old Blackberry. Especially if you have autocorrect.
This does not compute. I am a fast typer on all mediums, but a touch screen is just so slow compared to physical. I think I got around 80 wpm on my blackberry, there is no way I could do that on a touch screen. And iPhone autocorrect is terrible with any sort of tech jargon - frequently causing manual corrections.
I worked at a school that used the Frog VLE. 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 th…
And, to be clear, this has nothing to do with "classroom". The problem is people design these things without any sort of actual testing in actual conditions where the software is supposed to be used. Displaying 5 results per page is a bug, not a feature. Having restrictions on filetypes is a bug, not a feature. The same could go on to the rest of their "features". (My biggest pet peeve is date formatting — just give…
I’ll do YOU one better.
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.
Earlier quoted context omitted.
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. Bingo—the dysfunction of the software reflects the dysfunction of the organization.
I have my doubts that "complex unique organizational workflows" automatically means "dysfunctional organization."
Earlier quoted context omitted.
I’ve never had any trouble with typing on a touch screen just as fast as my old Blackberry. Especially if you have autocorrect.
Autocorrect is more often slowing me down. It's only rarely correct.
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.