Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Software The Internet

On Situated Software - Designing For The Few? 102

Posted by simoniker from the for-you-and-you-and-you dept.
janbjurstrom writes "Clay Shirky has published a thought-provoking (and long) essay discussing the concept of 'situated software', musing on changes in software development, from general systems catering to thousands towards applications 'form-fitted' to small, specific groups and particular social contexts. A lot of interesting observations about the differences." Shirky argues: "Most software built for large numbers of users or designed to last indefinitely fails at both goals anyway. Situated software is a way of saying 'Most software gets only a few users for a short period; why not take advantage of designing with that in mind?'"
This discussion has been archived. No new comments can be posted.

On Situated Software - Designing For The Few? More

On Situated Software - Designing For The Few?

Comments Filter:
  • The only reason software "designed for large numbers of users" fails more often than that designed for few is because there is a much larger userbase to nitpick and 'test' it.
    • Not really. The reason software "designed for large numbers of users" fails is that it is difficult to understand what all these options do. I've seen people who could turn double spacing on in Word 97, but not in Word 2000. Reason? IN Word 97, it was just "Use Single Spacing/Use Double Spacing/Use Triple Spacing." In 2000, it was "Use spacing: [2]" with a numeric control. As soon as it went from double to a number, people got confused. They didn't want that level of control, and they didn't trust th

  • I'd say (Score:1, Funny)

    by mihal ( 753927 )
    Everyone must write a new program every time he wants to do anything.
    And never reuse the code or use the same program twice.
    • Sounds a lot like the days when you would insert punch-cards into a terminal.. had to re-write everything back then too, was a living hell. :)

      I must admit, it would be interesting if the /. admin's had to re-write the main page in HTML, from scratch each and every time someone submitted something. ;)
    • I don't agree.

      I dont' believe that situatued software is contrary to the idea of code reuse.

      The only thing I beleve this approach is contrarian to is to the idea of "mass-use" software being developed to appeal to the lowest common denominator. Rather than ending up as trying to be something to everyone, the ideology here is more inclinded towards trying to be everything to someone (more or less).

      If you want to reuse code to attain the objective, it's surely fine. I mean it's in no way mandated that si

  • Yay - back to inhouse programming (Score:5, Insightful)

    by MrRTFM ( 740877 ) * on Thursday April 01, 2004 @06:27AM (#8735104) Journal
    I worked as an in house programmer serving 10 or so people (data manipulation, etc) and it was great.
    No specs, meetings, or other bullshit - they would say 'I want something that does so and so' and after a few screen prototypes, I'd go off and build it.

    *sigh* - these days it takes 2 weeks for a team of 4 to decide what database version to use.
    • Yep, sounds familiar.

      I used to work at a small local engineering company and they would say "We need a reporting program that takes the data from this Unix box and prints out nice reports in colour with plenty of options so we can select what prints." etc.

      I just started to knock-up a screen with a few tabs and buttons and we would take it from there. Changing bits here and there. Adding new options when we wanted them. It was great :-) I could add things if I wanted to without asking anyone, and chan
      • I used to work at a small local engineering company and they would say "We need a reporting program that takes the data from this Unix box and prints out nice reports in colour with plenty of options so we can select what prints." etc.

        These days you don't need to write custom apps to do that. You just import your data into an Excel spreadsheet and hack away at it. I guess "real" programmers don't believe this is the proper way to process data, but people are doing it in the real world all the time now.

        • Spreadsheets happen all to often. Then you get like 17 different lists floating around the office with highly redundant, but ever so slightly orthogonal data... with no revision control, and no common process.

          I myself am guilty of this as well ..because it is often the fastest way to just play around in a spreadsheet. But you should always stop and work with the IT staff to see if a better solution can be found.
      • Sounds quite a lot like what's behind Extreme programming [extremeprogramming.org] rationale to me.
        Do what the users want, show them what you do often so they can change it as it goes, and don't try to do more than they need, and, well xp recommends you try to keep it clean nonetheless so you can extend it if need be.
        However this is pretty hard to apply in real life,. Lots of people who are oblivious to both usability and technical constraints come in the loop and kill it all. They require plannings and time estimation to be ab

    • Re:Yay - back to inhouse programming (Score:1, Interesting)

      by Anonymous Coward
      You remind me of a small job I did when working with cadastral data for the city. We needed a util to help convert some of the data in its raw form into a better laid out format in order to sell some of the data we had to the public. I said I could get most of it done within a weekend, but that wasn't quite good enough; the project was outsourced, and 2 months (and several thousand $$ later) a bloated app came back to us that only worked usably with the quicker 3/4 of our workstations and had a GUI was fran

    • Re:Yay - back to inhouse programming (Score:4, Insightful)

      by jellomizer ( 103300 ) on Thursday April 01, 2004 @07:59AM (#8735325)
      But for many smaller companies you will need to put on many hats. Although you are the in-house programmer for most companies now in in this economy you will also need be able to do other jobs as well Like management, sales... and all the other stuff that a lot of techs don't like to do. If you do have a program to write you will need to spread it out over the rest of the other work you will need to do. A company of 50 employees cant usually justify to have a full time programmer paid at 45k a year. For the odd job that needs to be done (although they are often more then they think) Plus for these situations there will be long times that you are not programming because you made all the apps that the group needs to run for a while.

  • Also Known As... (Score:4, Funny)

    by femto ( 459605 ) on Thursday April 01, 2004 @06:31AM (#8735112) Homepage
    The Quick Hack.

    • Re:Also Known As... (Score:5, Insightful)

      by mystran ( 545374 ) on Thursday April 01, 2004 @07:22AM (#8735234)
      Not funny, but insightful!

      This is done all time time, people hack some throwaway code to do a simple task, which then grows for some time, until it reaches the state where it satisfies the 1 to 5 users it has, but can't really be transferred to another system/environment without so much hassle that nobody bothers to.

      Some of these hacks later become "real software", while most stay like they are. I'd claim that this is awfully more common practice in the Unix world, thanks to tools like bash/perl/python and the ultimate-unix-scripting-language C. But really, most software written in the world is VERY likely to belong into class "a quick hack".

      • Remember, be it good or bad, this is how Microsoft was started as well. MS-DOS comes from QDOS (The Quick and Dirty Operating System). This served as the foundation of Windows for years, and it grew from that. They're still having a great time trying to maintain at least a little bit of compatibility to with it.
      • Yes it's a case of "quick hacks". But the point Shirky was making was that it's not just any "quick hack", but a socially adapted "quick hack", AKA the right tool for the (one) right job.
    • Also known as...

      The guy that still has a job.

  • Admin scripts (Score:5, Interesting)

    by SavingPrivateNawak ( 563767 ) on Thursday April 01, 2004 @06:31AM (#8735113)
    Everybody doing a little admin on his linux box does exactly this...

    My scripts are very specialised and wouldn't be as useful to somebody else but they serve my purpose very well.

    Their limited scale is an advantage since I don't have to respect interface compatibility between versions, etc.

    This really eases the "upgrade" process when you think of a new super functionality-that-unfortunately-breaks-a-lot-of-t hings,
    It's my sole responsability and I am not blocked by others that would have different uses of the scripts and would not care about the functionality (but would care about the incompatibility!)

  • The key.... (Score:4, Insightful)

    by D-Cypell ( 446534 ) on Thursday April 01, 2004 @06:32AM (#8735117)
    The key to efficient software design is flexibility. Designing for the current problem while allowing the easy migration to more complicated issues (such has massive scaling up).

    I think the XP [extremeprogramming.org] guys outline this particulally well.

    Design for today, allow for tomorrow. Too much software is designed with only one of points in mind. The great software covers both.
    • I think the kind of stuff ebing talked about here is things that are too small for any process at all - no matter how extreme. And they are programs with no pretension for any kind of future scalability, becasuse they will never need it.

      The contrasts with a number of XP results I've personally seen where the result was , as you say, supposed to migrate up to better scalability - but because that wasn't thought about in design to start with, the end result was a mess.
      • yes, not everything needs that level of complexity. On the one hand, you don't cook a meal and throw away the pots and pans, but you also know that this isn't a meal that has to feed you for the rest of your life. Some things are utilitarian in nature and short-lived. Program accordingly.
        • Indeed. And the other thing to be wary of is that software can often expand in many different directions, and it takes quite a bit of experience and intuition to tell which ones are likely enough and/or easy enough to allow for. Often it's a good idea to solve the much more general case or allow for particular types of future expansion, but sometimes it's just not worth the extra work.
    • The idea being that if you know your audience, and they all know one-another, then rather than anticipating every contingency, you can create someting precision-tailored to the specific task.

  • More recognition and appreciation (Score:3, Interesting)

    by jsinnema ( 135748 ) on Thursday April 01, 2004 @06:34AM (#8735121) Homepage
    Personally I feel I get more recognition and appreciation when programming for a larger audience like the Internet.
    • Personally I feel I get more recognition and appreciation when programming for a larger audience like the Internet.

      I dunno, as part of a huge team consisting of marketeers, graphic design folks, and server-side Java kids, I felt like a cog in the machine more than anything.

      At another job, when I developed an app with a very small group of programmers to help some scientists run raw data through a pipeline and then display the results on a website only this small group ever used, I felt something like 50

  • The article continually stresses an alternate viewpoint to what is allegedly taught in web design schools, scalability.

    Not from what I've seen (or maybe it's taught but not followed?)

    Many of the code and sites I've seen have scalability problems, and those aren't the ones that explicitly say "not designed to scale."

  • ...small project teams in big companies end up developing sophisticated Excel Spreadsheets.
    • Yep... A small project team in a big company is not likely to have a C programmer and a DBA. But they all have access to Excel, and at least one of them with the {time|knowledge|inclination} to put together a really complicated spreadsheet.
  • I think what the article is talking about is an edge of what is going on all over, things like RSS feeds or other things that become small pieces of a very custom application for many users.

    In a way it's sort of the "UNIX way" of thinking, having a lot of small tools and linking them together to complete a task - only at a higher level and with richer building blocks.

    I think the challenge for anyone building and selling software that wants to ride this new wave is then to say - how can we create software

    • Re:New software scaling needs in distribution... (Score:5, Insightful)

      by Anonymous Coward on Thursday April 01, 2004 @07:00AM (#8735179)
      One of the major points of Unix design is that small programs are more usefull then big ones. Ones that incorporate a menu-driven user interface are less usable then ones that can receive input and output.

      Every program is a filter.

      Information in, modify it, and information out.

      That's it, that's all that programs do. So menu driven software only takes information from one source (the user) while input/output style programs can take information from many places.

      So when designing a program you need to figure out what it does, find out how to get it done and finished in the simpliest way possible, and then make sure that it isn't going to f*ck that up. Anything extra is a liability.

      Small programs are much longer lasting. You code one piece of software, why is it a good idea to code the same functionality over and over again? What? Wasn't the first 30 times you wrote a function good enough?

      Take the "cat" command for example.

      When will that never be usefull? It was used years ago and will be used years from now. You can take the code and incorporate it into other programs, but the functionality and the nature of the programs will awlays be there.

      You want to dump the output of a text file anywere, into anything? Cat can do it. It can copy files, can be used to provide information to other programs, it can take any information from anywere and move it anywere else.

      You know a easy way to ruin "cat"?

      Make it go: "Are you sure you want to cat this file? Y/N"

      Instantly useless.

      Weird stuff, userfriendly 9 times out of 10 equals user useless.
      • Indeed, I've been ruined countless times, in just that manner. Shameless.

        theCat
      • One of the major points of Unix design is that small programs are more usefull then big ones. Ones that incorporate a menu-driven user interface are less usable then ones that can receive input and output.

        Which only makes sense when you are a programmer. End users aren't going to learn the gritty on the "cat" command.

        When you see "user friendly" read that as "gets done what the user needs done without too much fuss". Deliver that, and you'll get paid.

        I can just see it now - you're dealing with a 55 yea

  • I don't see it... (Score:2, Interesting)

    by sirdude ( 578412 )
    This just sounds like "propietary/custom" written software rather than "situation" software, albeit combined with a certain degree of marketability predetermined during design, which is usually not the case.

    It also outlines something similar to the "Google vs. Yahoo" design debate, where Google has gone with the "The user has come here to search, so lets let him search the fastest and the quickest", while Yahoo has gone with "Search is just one of our products - lets give the user a ton of options and draw

    • Re:I don't see it... (Score:4, Insightful)

      by Anonymous Coward on Thursday April 01, 2004 @07:30AM (#8735249)
      Basically, situation software just sounds like a repititious new-fangled jargon to me..

      I agree.

      The point to successfull software design is:

      1. Find out what the user wants to be done.
      2. Do it
      3. Don't screw it up

      Bad software design goes like this:

      1. Figure out something to do.
      2. Make it look cool and make it fast, or at least increadably feature rich.
      3. Try to convince people to use it.
      4. Make it look flashy, and with that flash hide the functionality so that people depend on it without understanding it.
      5. have lots of options.
      6. make it so people can use it without thinking.

      (6 months later)

      7. Fix the horrible mess we just made.
      • I think Shirky's point is more than that good design is important, but that design for small groups is inherently better -- and I think it's wrong because of that. The main benefit of targetting small groups is that it makes step 0, which you didn't list but is the MOST important step, much harder to screw up:

        0. Identify who, and what situations, you're designing for

        If you don't do that, you'll design crap that doesn't do anything well for anybody. If you identify your user and what they're doing, you a

    • This just sounds like "propietary/custom" written software rather than "situation" software...

      Not at all. Many free software products start out small, just for yourself (scratching an itch) or a small group of people near you. I have seen so many failed attempts at solving all problems at the same time. A few years back, lots of companies died because they spent so much time in the initial development cycle that all their money and support suddenly were gone. Many big programs today wouldn't have been wri

  • Er guys? Did you know which day it is? I mean, what's up with all those interesting and important news?!
    It's 01/04, don't ruin my day, Slashdot!

  • No wonder /. doesn't work so well (Score:3, Funny)

    by whimdot ( 591032 ) on Thursday April 01, 2004 @07:24AM (#8735238)
    Too many users and the social fabric has broken down. The application has attempted to scale and it copes, in so much as the servers staying up is a measure of success. But look at the contents these days.
    • It's always the "hubris" part that screws things up. We always want to appeal to the maximum number of users. For example, what's wrong with having a mailing-list that has a 50-member limit (unless there are commercial considerations)? I once ran a Catpower mailing-list which was great until we reached about 200 members. At that point you start observing obnoxious behavior, because people feel like that they are "more anonymous", so they can do whatever they please. Also, the slightest thing can risk offend

  • Now the question is... (Score:5, Insightful)

    by Wiktor Kochanowski ( 5740 ) on Thursday April 01, 2004 @07:35AM (#8735261)
    ... how to capitalize on that trend?

    How to market yourself as a developer (preferably independent) so that you can make a nice living doing this kind of localized software?

    This is what's on my mind as I contemplate starting my own software company. I noticed the same thing as the author: there's a lot of demand for "small" software which is not being met, or is being met by second- and third tier programming talent, and the quality of results is quite often offensive.

  • target (Score:2, Insightful)

    by zby ( 398682 )
    I think there is nothing to justify that new name - 'Situated Software' seems to be just software with a narrow target. The whole rant with all examples is just stating the obvious truths about targetting. Perhaps there is an argument that when programming is easier (with better hardware, languages and libraries) then it economic to target it on narrow groups, but that whole story is a bit overblown.
    • <MODE type=old_git>

      *leans on walking stick*

      When I where a lad, 'twere called "vertical markets".

      </MODE>

      Valid concept, but I think it's just specialisation of market with new clothes.
  • I just found out what slashdot editors do all year: they prepare for this day, year after year, to make April 1st the great holiday we geeks deserve! Thanks! Oh, and if you ever need a job, Google is hiring [google.com]...

  • Other advantages (Score:3, Informative)

    by f8ejf ( 755486 ) on Thursday April 01, 2004 @08:11AM (#8735353)
    I own/maintain several very specialized programs.
    One of them, CWirc [easyconnect.fr], has a known target of maybe 15 people, and another 50 occasional users. And everybody who uses the program seems to like it a lot, because:

    It caters to their specific, specialized desire

    I have time to implement or improve things by request, to fit someone's wish almost to a tee (meaning, I don't have to make compromises)

    The project is so low-bandwidth and simple that I can make it evolve exactly like I, and the few users, want, at the pace I want

    So, while big projects with wide audiences are good, small (and also very small) ones with a very small audience have their place too. That's what makes open-source / free software work, because Microsoft and the likes don't have time or money for smaller projects, and big generic ones often don't do what people want.

    73 de F8EJF

  • MySQL (Score:2)

    by Tarwn ( 458323 )
    I'm still trying to figure out what that cheap MySQL plug was in the middle...

  • all about the situation (Score:3, Interesting)

    by timmarhy ( 659436 ) on Thursday April 01, 2004 @08:15AM (#8735368)
    it is a perfectly decent job writing customised software for companies. pays very well and has much less stress then working for big software firms ( which you won't catch me dead doing ) i wouldn't ever take a job writing a webserver for example, i'd just advise clients to use apache and charge then do setting it up. but if someone wanted say, an appointment book system which reflected their unquie busniess requirements i'd do it in a span. it serves them exactly what they need and theres not need to wait for some development house to get off their arse to make changes if they need them.

  • There is an intermediate level. (Score:5, Interesting)

    by AlecC ( 512609 ) <aleccawley@gmail.com> on Thursday April 01, 2004 @08:17AM (#8735374)
    An interesting article, but on the other hand you can look at it the other way. Larry Wall developed perl because he was fed up with writing special pupose report analysers, and built a general purpose report-analyser-generator - which turned out to be mind-bogglingly useful for other things. But it is a good idea to avoid feature creep: there is always a tendency, if not resisted, to add global features to a quickie "just in case".

    But the article was talking about a geograpically close-knit community. I write software fore spcialist machines used by a technically close-knit community. As such, my user interfaces can take advantage of their knoledge (for example, you can assume that a video editor can do timecode arithmetic). The trouble is the marketing droids don't have these skills, and try to force the UI to have features to make it iasy for them to use, rather than the end user. So they want every timecode box laden with calculating abilities, and boxes to show differences between timecodes etc. Lots of screen area, lots of niftiness - "look, I enter it here and it changes over there", but not much use. Luckily, my corporate culture allows me to fight back - "It's not for you, dummy, it's for " carries some weight. The problem sometimes comes with the customaer management, who pay the bill but are not themselves users. All you can ope is the users can control their management like I (sometimes) can mine.
    • To use the Perl example, suppose one created a tool to create Report Style A, and then reused some of the modules to create Report Style B, and so on.

      The idea of having a lot of little tools (Report A tool, Report B tool) seems attractive, but then one has the support burden of modifying all of those little tools. It seems easier to either 1) consolidate them into a general purpose report tool (the typical Swiss Army knife app) or 2) bundle the supporting modules into a library and passing off the respon

    • Great example. I'm definitely glad Perl managed to avoid the trap of bloat and creeping featurism so well!

  • Everything old is new again (Score:3, Insightful)

    by Asprin ( 545477 ) <(moc.oohay) (ta) (dlonrasg)> on Thursday April 01, 2004 @08:22AM (#8735400) Homepage Journal

    Didn't we try this already? I mean, wasn't the Y2K problem largely caused by this kind of thinking along with compelling limitations on hardware? You know, "Let's just design it for the hardware we have and when cheaper for powerful hardware comes around, we'll rewrite it." At least that's what TV says.
    • Ummmm. There *was* no Y2K problem. Or perhaps you didn't hear that *nothing* happened?

      • It was a problem right up until 23:59:59 on 12/31/1999.

        A lot of man-hours and cashola were spent rewriting software and upgrading systems to avoid it. I would even be willing to argue the IT spending bubble of the late 90's, (and even the horribly accelerated acceptance of Windows NT 4.0) was not caused by cheap ubiquitous internet access, but by Y2K. Sure, internet speculation contributed, but it wouldn't have had nearly as sizable a foothold among financiers if market expectations weren't already infla
      • Why don't you try googling for Mar 19104 [google.com] if you think there are no unresolved Y2K problems?

        Some things were prevented from breaking -- most of the major issues. Some things broke but were quickly corrected. And some things, as that search will show you, broke and are still broken.

  • Ya know this article is right. We shouldn't program for the masses, just individuals. We should be able to put up colored modules and let people 'Draw' thier own personal applications.

  • UI and other issues (Score:3, Interesting)

    by kisrael ( 134664 ) * on Thursday April 01, 2004 @08:34AM (#8735436) Homepage
    One of the small issues is sometimes it's bad when every little program has a new UI to learn. Not that big a deal.

    Actually, there's a related issue internal to development: I find small do it from scratch implementation much better than applying some massive pre-existing gramework, ala EJBs in J2EE; when you build from the ground up, directly task-focused, and understand how to reimplement the parts of the giant framework ou need in a fairly quick way, I think you get a lot more done than trying to munge some massive beast which always seems to be doing almost, but not quite, what you want.
  • Programmers make software to suit their own purposes. Maybe it is for a specific task at work, maybe it is for altruism. But there is no moral imperative to only write code for the benefit of humanity.

    There are many, many tasks out there that are "orphans" in the software world. Much like Orphan Drugs, there is not enough of a demand for large organizations to support them. So personally writing code to support a specific function is the only way to get it done. Why require that a developer with a

  • Often good technique (Score:3)

    by rjstanford ( 69735 ) on Thursday April 01, 2004 @09:00AM (#8735519) Homepage Journal
    This can be scaled up to Enterprise levels as well. The code moves away from the "quick hack" standpoint, but the goals can stay the same. Rather than trying to write an uber-app, you have a very solid, very consistent shared data layer (either a database or a set of business objects), and then tons of user specific (or role specific) applets feeding from it. That lets you have your core architecture team modeling your business reality, and your user-facing teams out talking to the users, building use cases, and writing software to solve specific problems. Cuts down on the size of the apps, and also reduces training costs as each user or group of users have exactly the software they need to do their job - no less, and specifically no more.

  • Isn't that what most programmers have always done? (Score:4, Insightful)

    by mwood ( 25379 ) on Thursday April 01, 2004 @10:30AM (#8736199)
    Think of all the guys'n'gals slaving away at payroll programs designed for one company. Not exactly a wide audience, but OTOH the one company gets an exact fit to its needs.

    Thing is, most payroll programs are pretty much alike, so there's opportunity for some vendor to offer a somewhat poorer fit for much less money than custom-tailored software. Some customers will be happy enough with off-the-rack software, but some will have needs or desires that still prompt them to pay the price for a one-off system.

    I believe there'll always be a market for custom-tailored systems, but it will shrink. The off-the-rack software jobs are the ones going overseas, just as was done in the garment industry. It's still hard to do tailoring over the phone, so those who need it will still patronize local talent.

    Moral of the story? If you want a long career making good money in software, one way is to seek out the work that has no mass market, and the single-use projects. It's hard work, but that's what makes it worth more.
    • Forgot to say that the work is always new, so it's more fun too!

    • ERP = Made-To-Measure (Score:3, Interesting)

      by Vagary ( 21383 )
      As I understand it, ERP systems are a hybrid of your two approachs. Basically made-to-measure rather than bespoke or ready-to-wear: ERP systems typically are an infrastructure requiring customisation for each enterprise. Since customisation is simpler and in a higher-level language than creating a system from scratch, the cost of the ERP software plus customising developers should be cheaper. (Many made-to-measure and even bespoke tailors are offshoring the stitching today.)

      Of course many small businesses
  • Many in the environmental community have made this argument as a general principle: products should be designed with a local focus. For a fabulous example, think about soap/detergent. Given how much the content of available water changes around the world -- different minerals in different proportions -- wouldn't it make sense to have cleaning products that are specifically made to work best for your situation? Instead, everyone washes their clothes with Tide, and most of us have to use more of it than shoul
  • ...or has never worked in a business environment.

    I don't have enough fingers or toes to count the number of "small apps" that some wonk wrote to make life easier for a few folk (maybe an excel spreadsheet + macros) that ended up living long after their creator left the company. The people who use the app have no clue how to do the job manually, just how to run the macro ("Simply open whtzits.xls and click the "RUN" button"). Then something breaks or they need new functionality and it is YOUR job to wade th

  • What the author keeps describing, but does not specifically articulate is that the 'situational software' is more implementable and works better because it uses a different set of assumptions in the design.

    This set of assumptions is based around what features can be eliminated because of the small group. E.g., they could eliminate a reputation system (a la eBay) because they assume that the set of users already know everyone's reputation.

    What is the best code? Code that is never written -- it takes no t
  • Writing your own home-grown app is a function of how hard and how expensive it is to do. With pretty simply WYSWYG tools like Dreamweaver that has good support for making data-driven apps, anyone willing to take a week to learn can do it. But if research projects underway on allowing "programming for dummies" tools hits the mainstream -- Clay's observations will really come true. If you can use a combination of natural language, and drawing information diagrams with icons, then literally anyone can write a
  • Kiosks have always slightly mystified me, and it seems that what Shirky is describing is relevant to their design, although because his angle is that he has discovered a new phenomenon, he doesn't mention them.

    Airports, stations, public buildings... trackerball, touchscreen, crash, crash, crash. Ever since about 1993. They're still around though, and being consistently ignored by all who walk past them.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close