Information Systems: The Human Factor


Cohen, S., Dori, D., & Haan, U. D. (2010). A Software System Development Life Cycle Model for Improved Stakeholders’ Communication and Collaboration. International Journal of Computers Communications & Control INT J COMPUT COMMUN, 5(1), 20-41. doi:10.15837/ijccc.2010.1.2462
Kopliku, A., Pinel-Sauvagnat, K., & Boughanem, M. (2014). Aggregated search. CSUR ACM Comput. Surv. ACM Computing Surveys, 46(3), 1-31. doi:10.1145/2523817

Coming to the world of digital information systems as a complete novice and from a place of total ignorance as to how software is developed, I have to admit I found Shalom Cohen, Uzi De Haan, and Dov Dori’s article, “A Software System Development Life Cycle Model for Improved Stakeholders’ Communication and Collaboration,” somewhat horrifying. This isn’t because of anything the authors do or say in their explanation of their explanation of a new software system development model: By developing a software life cycle model that takes security into account and involves regular interactions with clients, they imply that previously, developers did not take security into account or pay much attention to user needs. They don’t answer the question, though, of why not. I can imagine a sector that encouraged elegant mechanistic solutions to theoretical problems, regardless of whether those solutions actually worked when messy humans started stumbling around the system, with their incoherent questions and negligent ways of leaving digital doors open. Though Cohen, De Haan, and Dori don’t get into the specifics of security in their article, their Lead Driven Development model does amply provide for user feedback and input into the development process. That means a potential client can more easily butt in with questions like, “Yes, that way of accessing information works for me, but how do I give access to the person I’m consulting for…and no one else?” Such a question makes the developer come face to face with a security issue he or she hadn’t considered when the software problem to be solved was just a pretty flow chart and examined only by fellow programers. The question is, why wasn’t this happening before?

It’s not the only question the article prompted in me. Mainly, I didn’t understand how all of this client interaction, particularly from different departments in the client’s company, their statement at the beginning of the article:

Two major trends dominate the software development world today. The first is the shift of organizations from fulfilling their own software requirements in-house to buying it on the market, either as an off-the-shelf packaged software product or from a company tailoring a specific solution.[1] The second trend is the shift from developing tailor-made software to purchasing packaged software from vendors either in stores or directly from the vendors.

It sure sounds like their LDD model is for the development of “tailor-made software” for specific clients, what with all the client input looping back into the process as it goes from stage to stage. Perhaps the developers work with a particular client when the system is first being created, and then once both developer and client are happy enough with the results, the developer takes it public in an off-the-shelf form? Cohen, De Haan, and Dori don’t say that explicitly, but it does make a certain sense.

But while Cohen, De Haan, and Dori seem happy to take the human factor into account when developing software, Arlind Kopliku, Karen Pinel-Sauvagnat, and Mohand Boughanem seem to blithely ignore it when they write of efforts to develop more sophisticated results from user Web searches in their article, “Aggregated Search: A New Information Retrieval Paradigm.” They write of the desire for web searches to turn up information “nuggets” from a variety of sources and in a variety of forms when users type in a search term instead of the lists of documents that turn up now. They imagine a search result that fits the users’ needs quite precisely, organized in a way more useful to the searcher than articles ranked by popularity. There’s one problem: Computers still can’t read users’ minds. They admit as much when they use the word “jaguar” as an example of a search term: does the user mean the car, or an animal in the South American jungle? And just what does the user want to know about this jaguar, anyway? It’s reproductive cycle? How it hunts? Or its MPG? I can see aggregated searches being realistic for very sophisticated users. The problem is, most of us aren’t that sophisticated.


Bye-bye, Blog!



So often this semester, the readings for LSC 555 have left me amazed at how quickly technology changes, and wondering how libraries can ever keep up…or, even if they should try. The readings we were given to choose from for our last blog post are no different. I read “Analyzing RSS Applications on Library Web Sites” by Tanmay De Sarkar and my first thought was, “Wait. People still use RSS?” And I’m something of a Luddite, a late rather than an early adopter! The article was only published four years ago, but when it comes to information technology, that might as well have been a literal, not digital, generation ago. RSS does seem to be an eminently useful technology and one less dependent on correctly guessing trends than many other technologies. So why does it seem so passé? Is it because we are all—librarians and users alike—victims of the decreased attention span rapid change brings on?

Bohyun Kim’s chapter on “the mobile library experience” both suggested what may be a replacement for RSS feeds and graphically demonstrated the rapidity of technical change. If you do most of your work on your phone, and you can sign up for automated text messages to your phone that tell you when a book is coming due and that kind of thing, then why sign up for an RSS feed that does the same thing? I can’t say why a text message would be better than an RSS feed—they both seem to me to do the same thing, at the same speed, with the same amount of work for the user to sign on—but if that’s the trend now, I suppose librarians, with their limited resources, should focus on SMS instead of RSS or divide their attention between the both of them. They also, apparently, should make sure the full capabilities of the library’s websites are accessible by telephone. This means searchable databases, the full catalog, personal account adjustments…the works. The surveys Kim cited and the screenshots he provided demonstrated how dominant smartphone technology became in just the three years between 2000 and 2013, when he wrote the chapter. Earlier in the semester, I would have said it was astonishing, but by now, after reading article after article that were only a couple of years old yet touted some now widely-accepted technology as the Next Big Thing, I’m no longer astonished. I do rather wonder what comes next—because there will be a “next,” within just a couple of years if past performance is anything to go by—and what its costs will be, in terms of dollars and cents but also in the loss of privacy.

I can’t help but feel that we as a profession at least, and maybe as a species, can’t keep this up. We need to settle on something, to rest and find some stability in the way we talk (literally or virtually) with each other and otherwise transmit information. As it is, technology has been developed and adapted in such a scattershot way, with so many different systems and languages and markups used by so many different institutions and patrons, that I have to wonder if it’s defeating the purposes of efficiency and transferability. Just as an example: Think of how many e-readers there are out there, utilizing different file formats and operating on different platforms. Perhaps it’s fitting that my last post for this blog has brought me back to my first, experimental post, which may be floating in the ether but otherwise appears to be gone: A book is not an information system. It is, however, generally speaking, ergonomic, affordable, not subject to technical obsolescence, sturdy, portable, and frequently aesthetically attractive (there’s a reason so many e-book covers are designed to look like the traditional codex-style book, and e-book screen settings can be set to look like parchment or aged paper). Maybe it’s time librarians started looking in its direction again rather than running a futile race to keep up with digital trends.

Sources cited:

De Sarkar, T. (2012). Analyzing RSS applications on library web sites. Library Hi Tech News29(5), 4–21. doi:10.1108/07419051211262072

Kim, B. (2013). The present and future of the library mobile experience. Library Technology Reports, 49(6), 15-28,2. Retrieved from

I Hate New York


So I’m writing this from a Dunkin’ Donuts on on St. Nicholas Ave. and 145th St. W. because not only does the place I’m staying not have wi-fi or other internet connections (which, in fairness, they warned me about) but the nearest cafe with wi-fi won’t yet me use laptops there. So I wandered down the street for a few blocks and found this, which taps into the wi-fi offered by the subway station below. Which is a thought: just sit in the subway with my laptop. Except that New York doesn’t seem to believe in elevators, for subways or much of anything else. I’d have to haul this thing up and down at least three flights. My knees are already complaining Dunkin’ Donuts it is.


I was stunned by the Australian YouTube video we were assigned for week 9. Not that it was that bad a video, but because it seemed the least likely one to use to encourage accessibility in your websites. The noise! The colors! The flashiness! I can think of a dozen disabilities, easily, that this video would accentuate. It, honestly, seemed like the kind of thing that could trigger an epileptic convulsion, or migraines for people who have trouble with flashing lights. And much of the message was fed through the medium of musical rhythms…which you wouldn’t get if you were deaf. Now, granted, I haven’t looked at the code (not that I would understand it very well even if I had…) so maybe they’ve worked around these things so that the text is narrated for the visually impaired, for instance, but still, the irony abounds.

It is interesting, though, how much overlay there is between usability and accessibility. Take Nilsen’s “10 Usability Heuristics for User Interface Design,” for instance. “Aesthetic and minimalist design: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.” Doesn’t that fit in well with designing for accessibility? For instance, too many colors (see: that damned video). A clean palette muse be easier for people with color-blindness to use than one full of clashing and extraneous colors. Also, a minimalist palette would mean the designer is making the site usable for people with a wider range of varieties of color-blindness. I don’t know a lot about learning disabilities, except there are many of them that require many different adaptive strategies, but it makes sense to me that Nielsen’s rules about “Consistency and Standards” and “Recognition Rather than Recall” could only make it easier for people who have reading disabilities to navigate a site than if the designer gets–shall we say–too creative with links and symbols.


Nielsen, J. (1995). Ten Usability Heuristics for User Interface Design. Retrieved from

Australian Government Department of Social Services. (2012, May 2).
Web accessibility – What does it all mean? [Video file]. Retrieved from

The picture is all mine, taken in Central Park 11/5/2016, with the Catholic University chapter of the SLA.

HAL 9000 Goes to the Library


Am I the only one rather creeped out by some of the technology Rachit Gupta wrote about in his “Human-Computer Interaction: An Overview”? I’m not sure I want computers to be “ubiquitous” in my life, though I don’t know that there’s anything I can do about it at this point [Gupta, 1737.] I do know, emphatically, that I don’t want my computer to engage in facial expression analysis or auditory emotion analysis [Gupta, 1738]. What’s wrong with a computer doing what you tell it to do, and no more? (Well, okay, I know what’s wrong with that: we tell it do do the wrong thing, or don’t tell it what to do explicitly enough, so that it returns, in effect, gibberish.)

I’m trying to come up with a way for these technologies to be truly useful, as opposed to entertaining. (“Look what happens when I make this face!”) I did a story as a reporter in the early 1990s about how advances in computer technologies have greatly improved the lives of many disabled people by allowing them to do useful and fulfilling work, and the interviews I did really stuck with me. So I look at a lot of new technologies through that lens: maybe this will help people who struggle to communicate, or whose bodies won’t let them use more conventional technology. I consider a young relative of mine who has severe cerebral palsy and ask how facial expression analysis or auditory emotion analysis might make his life better, and…nope, not coming up with anything. I am coming up with incredible invasions of privacy the likes of which we may not have thought of because they don’t involve documents. Because somebody’s on the other end of the camera and/or microphone when these technologies are used; I doubt if the user data is just dumped into an unhackable hard drive in the user’s own home. Then what?

One “what” I can think of is that the data regarding a user’s (okay, let’s be blunt here about how we think about these things: not some theoretical user, but MY) expressions and emotions become proprietary information for some private company. Which is a not-so-good transition to my thoughts on discovery tools.

Discovery” is good, right? And tools that help one discover is good, too…right? As Asher, Duke, and Wilson put in in their paper, “Paths of discovery: Comparing the search effectiveness of EBSCO Discovery Service, Summon, Google Scholar, and Conventional Library Resources (Asher, Duke and Wilson, 2013),”

Discovery systems…address students needs by enabling cross-database access and access to sources they feel they can trust, especially when compared to Google (Asher et al., 2013).

But they go on to say:

[T]oo few students understood how these [discover] processes and algorithms work, a problem exacerbated by the proprietary designs and complex coverage agreements of the discovery tools themselves (Asher et al., 2013).

I added the emphasis there because it’s what gets to my point: Information is becoming increasingly proprietary. On the one hand, you can say discovery tools allow students to access information as never before. But on the other hand, you can say they’re only accessing the information the proprietors of the discovery tools want them to have. I don’t mean for this to sound like a conspiracy theory—I don’t think the Trilateral Council is controlling this or anything—but it is something to think about. Who gets to decide how information searches work, and what information people access? And who gets to use that information? Other articles in this week’s readings mentioned proprietary library systems, and how some of them work only with certain databases and not others, and only allow certain levels of customization and access because of their proprietary nature. I keep thinking of the old-fashioned image of the librarian with her cards and card catalog and pencil in her bun, who knew everything there was to know about her system and could take her skills anywhere. Is this really so much better?

All that said, after performing a literature search on another topic and being flooded with articles, I have to wonder if the problem actually is that we have too much information, point blank. But that’s for another post….



Gupta, R. (2012). Human computer interaction: A modern overview. International Journal of Computer Technology and Applications, 3(5), 1736-1740.

Asher, A. D., Duke, L. M., & Wilson, S. (2013). Paths of discovery: Comparing the search effectiveness of EBSCO Discovery Service, Summon, Google Scholar, and Conventional Library Resources. College & Research Libraries, 74(5), 464-488.

Images are stills from:

Kubrick, S. and Lyndon, V. (Producers), & Kubrick, S. (Director). (1968). 2001: A Space Oddysey [Motion picture]. US & UK: Metro-Goldwyn-Mayer (MGM) & Stanley Kubrick Productions.

Image 1 accessed from:, 10/14/2016.

Image 2 accessed from:, 10/14/2016. Altered by the addition of a caption by Jones, K.E.