November 15, 2007
Reginald Braithwaite writes consistently great stuff on his blog, but I think my absolute favorite thing he's ever written is We Have Lost Control of the Apparatus.
But we programmers have lost and we must be realistic about things. The fact of the matter is this: people own their own computers, and our applications are no longer the primary way they learn how computers ought to work. I know, I know, they stare at our work for eight, ten, or twelve hours a day. So you would think that we would set the standard for how computers ought to be. But the Good Old Days when most of users had never seen a computer before work have gone. Some of our users, fresh out of school, have already been using computers for ten years!
As if that wasn't enough, the really bad news is, when our users go home they have this thing called the Internet. I know, IT locked that down in the office. But we can't stop them from getting on it at home, on their mobiles, and now even on those insidious Apple iPods! And when people use the Internet, they are actually using other people's applications. I'm not kidding. Our users are being exposed to applications we don't control. And it messes things up. You see, the users get exposed to other ways of doing things, ways that are more convenient for users, ways that make them more productive, and they incorrectly think we ought to do things that way for them.
Over the last five years, the internet has evolved from a traditional HTML content delivery system into an application delivery platform. One that competes with every sort of software application, not just other websites. Every bit of software we write, on any platform, is judged against things users are already doing on the internet. We're all competing with the internet.
Reg provides a number of specific examples where internet applications have raised users' expectations. Possibly the greatest shift in expectations is around search:
[Google] is practically the home page of the Internet. Which means, to a close approximation, they are the most popular application in the world.
And what have they taught our users? Full-text search wins. If you give them a search page with a field for searching the account number and a field for searching the SSN and a field for searching the zip code and a field for searching the phone number, they want to know why they can't just type
4165558734 and find Reg by phone number? And right after we make that work for them, those greedy and ungrateful sods'll want to type
(416) 555-8734 and have it work too. Bastards.
I have tried explaining that there's an ambiguity if an account number is also
4165558734. They think we should just show them what we find and let them sort it out. They're idiots, obviously, but they're our idiots and I'm pretty sure that if we fire them all we'll have to clean our own desks out the following day.
This is particularly hard on the internal applications Reg seems to be focusing on here. Internal apps are already the shakiest part of the software ecosystem; as Joel points out, lots of internal software sucks pretty badly. (I know because I've certainly written my share of it.) Having this pervasive, instantly accessible world of reasonably good software available through your browser-- and it's only one tiny click away -- is like pouring salt in the user's wounds. It's impossible to justify the pain of badly written internal software when there's a universe of better choices practically beating down your door, even on locked down corporate desktops.
If I was a user, I'd be angry, too. If you're writing software that you want users to actually use, then no matter what kind of software you're delivering, you better pay attention to your online competition. It's going to be rough, even for commercial desktop applications. I'm not sure many internal applications can legitimately compete with superior options emerging on the internet every day. It's survival of the fittest alongside a vibrant new species of internet competitors -- does your software deserve to survive?
Posted by Jeff Atwood
Three words: cost versus benefits.
When you're application is just one search field for anything and everything on the net (ie Google), that one search field had better do a lot! It's their primary business (ignoring all the other apps they have that don't make any real money).
Whereas for most other software companies search is only one feature of many. They just don't have the resources to allocate to do an amazing powerful search algorithm. Nor the hardware resources to make that happen. It might just be a small part of the whole application.
For example a software application like ZoneAlarm (free firewall software) will most likely only have rudimentary searching of their log files, if any at all. It's a minor aspect of the application and not worth the cost. It would be great to have, but the ROI (return on investment) just isn't there. They're much better ahead focusing on improving the quality of the firewall than in improving the searching capabilities of the logged events.
And I absolutely agree with you that unfortunately we're all competing with the whole internet, which means that we're indirectly competing with companies that offer very specialized features such as Google's searching. And because of this our customers expect to see these very highly specialized features as standard features in all software applications.
That's the reality of today's market.
The industry is still in a state of flux, yes there are AJAX enabled apps and ubiquitous search; yes there are users that have been using computers 10-15 years now. There are, however, still users who are sitting down to a computer for the first time. How computer literate are most of our parents?
I've helped build an application for the financial industry and many of the end users of the program are professionals and are computer illiterate. I saw an ad for a software developer two weeks ago where they were looking for someone that was keeping up with the latest technologies so they could build and maintain applications in VB6 and DAO (yes DAO).
The Internet will help our industry by showing our end users better UIs than they are getting at work, this is turn will have them demanding that their internal apps be more user friendly, which in turn will encourage our profession to be more professional in application design and development; no more bosses brother-in-law wrote a macro so he can build our enterprise app for us.
Maybe it will even help with product design UIs like those microwave ovens Jeff showed a few weeks back; or being able to program the clock on a VCR (I know, who even has a VCR anymore).
Its all economics.
An application has 10 million users, costs $100 per copy and supports a development staff of 100. It has top-notch user interfaces.
An application has 1,000 users, costs $10,000 per copy and supports a development staff of 10. There is a good effort on the user interfaces, but there is a clear separation from the world class.
An application has 100 internal users, costs $100,000 to develop and supports 2 developers. Its really doubtful they will have the resources to make a world class user interface.
Sadly, companies would be well advised to buy a pre-made solution and conform their process to it.
The problem is that for ever person who knows what they are doing there are still loads that don't. My parents (showing my age :( ) spend there working days, 5 a week, in front of the computer but the minute they get home its like they forget everything and always ask me to do everything and sort everything on our computer for them. Its hard to write software for those that want to be guided and those that can guide themselves.
Uhhh, like about 2-3 years ago.
Oh man, I was actually just about to write about this same thing in my own blog. I was quietly lamenting to myself how it is virtually impossible to write a decent search function these days because people have been spoilt by Google. Even ignoring the pagerank system they have, the way it spell-checks your words and even automatically searches for similar words is amazing - the other day I did a search for someone's name (first name Kim), and it found matches of "Kim", "Kimberly", and "Kimberley". That's insane! How can we complete with that?
I was working on an internal app for a mega huge mortgage company (you know the one) and it mashed up their data with a map.
I plopped a big fat Search box and button on the top nav and told the developer "make it search all records at least for loan number, order number and zip code."
He about came unglued... I mean seriously, that's a simple union query and he didn't want to do it...
This is the why we as developers have trouble writing apps that people want to use.
"Do One Thing"
A quote I've heard echoed many times by Jeff. It's impossible to compete with a search engine like google when you're incorporating a search function into some kind of app.
As an example, my university homepage's (horribly designed) search function has no 'advanced search' box. I wish it did! The algorithm behind it all lacks so much, that it's virtually impossible to find a course outline with it. But can we really expect a 'simple' homepage to give the kind of functionality of dedicated search engines?
I understand your point - users have been spoilt by the internet - and all software has to compete with online applications. I think once again it comes down to the quote I used above; do one thing, and do it well. For all the extras, integrate your application with tried and tested applications.
@Daniel, oh how I agree with you. I offered to build the universal search engine into an application. Just type what you want into the box and the search would find all relevant hits for the item to be queried. It was not even a matter of extra time to develop as the full functionality had already been implemented in a prototype. The beauty was that the data in the different fields were quite dissimilar and incorrect hits were highly unlikely. The customer specifically asked for multiple textboxes for each field to be searched, though. If I wanted to get paid, I had to implement what they wanted.
Reading (pointing/clicking/browsing/searching) is something most humans can handle well.
Writing (Computing/editing/assembling/hacking) remains (and probably always will remain) something most people can't do very well.
It's only natural that mass adoption of computers will change their traditional role as the all-purpose editing/writing tool into the all-purpose information/media browsing/reading tool.
If you worked too hard searching for SSNs in 416,
then it's time to have some fun.
All the SINs you want in 212.
You guys are forgetting something:
WE (devs) know how these things work.
THEY (users) do not.
I once worked in a call center, it had two ways to open an account: phone number and customer name.
The phone number was obvious, type the 10 digits and click "search", the name was a bit more complex, type the account holder name, and search, find the name that matches the customer calling, and open account.
Many many people in there, people with more than one cell phone and a mac, didn't EVER touch the "search by name" button.
When asked, well, it was too much complicated. All the validation stole them precious seconds from their call.
In my experience, it usually was just a couple of clicks more.
However, in another occasion, I saw someone searching up to the page 50 or so from google for his two word search query, complaining that google was stupid.
If your software doesn't suck, you're not testing well enough.
Another strike against internal software is the fact that management is loathe to allocate resources to improve it since it isn't a customer-facing app, so it ends up being a giant exquisite corpse of development, with each new luckless team being thrown at it having to do their best to work around whatever junk is already there. I'm not necessarily talking about rotten code written by previous developers, either, though that certainly happens. I'm referring to technical limitations. For example, we've got to keep an internal system running here that was done in the days before AJAX, and the team that wrote it roughed in their own custom AJAX-ish solution that is tightly coupled across all the layers of the app. While we could certainly break it down and redo it with standard libraries, it's just time-consuming enough that no one wants to put in any free time since the reward will be nil, and management doesn't want us wasting any more time on it than absolutely necessary.
So it goes.
I'm lucky as 99% of the software I write is for myself. If I can automate a task then up comes the IDE. I must say it's not as fun when a bug pops up because the only one to blame for crappy code is myself.
its no coincidence 90% of the apps with horrible, awful, terrible coding, featured on worsethanfailure.com, are internal apps.
Hey Now Jeff,
Survivial of the fittest only the strong survive.
Coding Horror Fan,
I, for one, feel that a business should dedicate as much development time on internal processes (if not more, depending) as it does on its externally-facing apps. If the inner-workings are organized and handled well, then the customer will inherit that experience. It's the little things that "shine through" or "stink through". If I had a small sum of money for every time I had to "start my call over" and give my personal information again after being transferred, I'd have a large sum of money.
Seriously. I call up, authenticate, get transferred, and have to authenticate again to that next rep. Why? It smacks of crappy internal integration (i.e. a simplistic app used internally that doesn't tie into the phone system).
That "Full Text Search Wins" certainly resonates with me. Why is it that when I type a 10 digit number on a site that is *indexing books*, the search can't figure out that it's an ISBN?
Why do many search pages have the audacity to have an "Advanced Search" link, when it in fact should be titled "Hold the search engine's hand and help it search for this".
And it's not just internal apps. If I need API documentation, I have a command line alias that automatically submits a (used to be Google) Live Search query on the msdn.microsoft.com domain. It was actually faster to start IE and submit a query to search.live.com than it is to run the MSDN help viewer that's installed on my dev box.
If only this were the case. Unfortunately many of our clients _DEMAND_ searches with upteen fields as opposed to a "single search box". Sometimes I feel like pulling them kicking and screaming into UI bliss, but other times, I give in...
"Seriously. I call up, authenticate, get transferred, and have to authenticate again to that next rep. Why? It smacks of crappy internal integration (i.e. a simplistic app used internally that doesn't tie into the phone system)."
Yup - spent eight weeks trying to sort out a car insurance claim and had to confirm my address at the start of every one of the numerous phone calls involved. When they finally got round to mailing me important information, they sent it to the wrong house!
Comparing to Google search certainly is unfair, the average web application can't compete with that by far either.
Actually, it goes so far, that to search for something e.g. from Microsoft I use Google to search for "... site:microsoft.com" instead of their own search, because that one is just crap in comparison.
And they actually do already have real search engine technology...
Seems someone should program de programmers to write good software from the start :D
Google is common place nowadays, its googla here in my langauge.
If your software doesn't suck, you're not testing well enough.
deworde on November 16, 2007 12:11 PM
deworde, I dont think your understanding that we're not just talking about bugs, but general functionality and approach in some ways.
I remember writing internal apps, and yes, *most* could have done alot better, but gradually you learn that if your not on the button with features and usability these days, your nowhere. He mentions Ipod... what a classic example. Does what you want and sooo easy to use. I'd have done a course in that when I'd first started (boring as it may have been) my approach may have been completely different during those first years of development.
A lot of things has changed the last 10 years.
I work in a company that creates internal apps that work over the internet, thus solving all problems! The future is here!
I have some sympathy for the author, note "some" . . . not a lot.
I've had the opposite experience. I wrote an app for bringing up a person's information from a database that had several ways to look up that info. There was a unique id which always got you that data in one step, and you could also search by name ([last name], [first and last] or [last, first]) telephone number (7 or 10 digit, hyphens and spaces optional) or email address. These latter items gave a list of matches (and trust me, there were PLENTY of matches coming out of the database) and the user would have to sort through those to get what he wanted.
I wrote it with a single text box - it figured out what you had typed in and did the appropriate search for you. A very common response from the beta was that the users wanted a dropdown menu so they could indicate what they were searching. They seemed to want control over how the search functioned, even though none of the input types had the same formatting, making the dropdown completely redundant.
if users want google type searching, recommend they install google servers on their network and integrate. The Internet means we as developers must utilize other peoples systems in order to succeed. In the same way we don't start writing a new dataaccess tier for each project (I.e we use ado.net or jdbc etc), we must use what's available to us.
P.s why you don't want an iPhone yet? Jeff , come on!
I'm very lucky. All the code I write is for applications used only by me. (And occasionally my boss if I'm off to have surgery for a week; as I have this past week. He mucks things up, but he tries so I give him credit for that.) I don't have to interact with people as well so...OMG!!! I have the perfect job!
But those of you who write code for others to use? Qwitcher bitchen and write what tour customer wants or they'll go elsewhere. Then your job will be extraneous.
And Jeff? Why "no HTML"???
I don't get it. Well obviously if internal software competes with any shrink-wrapped product (be it MS Office or an equally polished internet application) the outcome will be clear. So what? Internal software is developed simply to the point of getting things done. Anything else would be just a waste of resources.
This of course does should not imply badly written code / bugs / no testing and so on.
An internal programmer.
I don't use software unless I have the code. Trust no one.
'You want better search? Fine! You have the source, add it yourself!'
...or did you get /money/ involved?
There is no such thing as a digital product in the future. There is only service. Think fast-- in some places, the future is already here.
Having started my career making web applications, I find the resistance to 'functional design' in traditional apps to be profound. Project heads, system and business analysts and all of their ilk have an 'old school' approach to development. What I have learned through years of web app development is that the puzzle is usually solved faster by starting at the finish line (the end user experience). This does not mean we need to abandon good data management, but what good is data management when the user hates using the software? hmmmmm...
Let's be honest here. Good software is software that sells - software that users like. My personal geek opinion should be sequestered to my geeky social network. My professional opinion should rely heavily on those innocent folk that have to use what I create. Many of my colleagues think that this is 'dumbing down' the UI. I believe that the reciprocal of this is true. When we make software that is intuitive and easy to use... with a small or non-existent learning curve, we are actually 'smartening-up' the software.
We have to stop thinking the entire world should be obsessed with the order in which tiny little electrons race through tiny little wires. If, for some reason the populous decides we have been right all along, and those electrons ARE the sum of our happy existence, we will spend our days in the unemployment lines, or worse yet... using software an non-geek created!
I believe we as programmers have a moral obligation to make our users hate their jobs. The more people quit their jobs, the better. Tell me, who really profits at all from this survival-of-the-fittest stampede towards nothing?
Haha, I used to have the multi-field search page on my biggest internal application, and I eventually got rid of it in favor of full-text. No complaints since then, and I don't even consider a multi-field search anymore.
Google forced me to learn AJAX, Wikipedia showed me how to lay out information in an attractive and readable fashion, Amazon showed me how to serve products to users based on demographics, and YouTube and Flickr showed me the value of an open folksonomy. If anything, we should be thanking these guys for inventing the wheel before we have to.
I know I may sound like a tool for using the ideas of others, but I'm only one developer, and although I consider myself smarter than the average bear, I can't compete with the best development teams on the web who are fueled by all sorts of RD and probably even have THEIR OWN TESTING TEAMS. Wow, that would be nice.
Did no one else recognize the original source of the "Ha ha I'm using the internet!!!1" picture?
All software sucks. I try to make mine suck less. I often fail.
It is, however, the ability to admit failure in this that is the first step to making it better. If the users of the software say that they would like it a certain way, you must help them. However, it is often not best to just do it like they ask, but instead, to know WHY they want it like they do, in order to not meet, but instead exceed their expectation. Often with less work on your part.
For instance, the users claim they need to be able to edit closed financial transactions. Instead of removing that edit, perhaps, you need to fix the place where it did it wrong to begin with so that they no longer need to edit them. Everyone wins.
Its better to buy a platform and then input your business needs to it. After that, you get new versions of the platform in a box and can concentrate in updating your business needs. You should only need one (1) platform that rules them all.
Maybe the users wanted to put down on "paper" with what they wanted to search so they would not forget it while they thought up a search criteria.
I like more applications that are wizard-like than applications that give you a complex but general form to fill up. The more steps a user function has, the more I want a wizard to it. Users might not have used to multipurpose search-fields, so they want a redundant combo box to it - even if there is only one simple field in it. Also that way they know what are the search options. They could not search with for example the employees pet's name.
I want my application to be easy to use. I dont want to look a bit of information from here and a bit from there and then go through this and that window to get a general form where I need to fill few and only few fields but remember not to fill the third field while I need to check five other field's data. Instead I want all the stuff in that function to a wizard or better into one window without everything that I don't need in that function.
I don't think google's advanced search screen is particularly easy to use.
There is also the other side of the coin. If you give a user one field to rule them all they may actually be afraid to put anything in it in case they think they need some arcane formatting or something. "But it doesn't say anything about telephone numbers, how will it know to look for a telephone number?"
Google has also put thousands and thousands of hours of analysis and development into their search tools. There is no way you can compete with that unless you can use existing frameworks. Apparently the latest version of XCode/Interface Builder lets you put drop search/filter fields into your apps that will behave like Apple's own, but I haven't had the chance to use it myself yet. It's really only a matter of time until that sort of thing is in all GUI toolkits.
Google search and application search not the same. Google is trolling the internet and indexing public known sites. Additionally it is applying relevance to each site (ranking). Basically it is indexing content.
Your appliation is probably stored in a database or file system or both. So a universal full text search is not feasible because the application is more than just content.
I would just listen to your users and ask them how they would find stuff in the application and build out search appropriately.
Google's image search is one service that is not working as I wish it would. Sometimes it shows pictures I was looking for, but many times not. For example if I want to look pictures of space monsters, I search space monster. But at least the first page shows pretty crappy space monsters.