A General Overview
I am most interested in the ways expediency might affect your goals in digital contexts when you pare your ideas down to fundamental components — do the conveniences of ready-made tools/code and the paralysis in the face of overwhelming quantities of learnable skills corrupt the integrity of the core ideas?
…but I will get back to these concerns in my provocation. First I’ll digest Chris Stein’s blog post a bit and attempt to point out some changes since its publication in 2011.
Chris Stein’s blog post offers a straightforward framework for building a digital project from inception to implementation. Addressing the best ways to simplify questions of use and users, Stein outlines guiding questions for prototyping:
- why or what need
- what you should build
- who is going to use it
- where you want to put it, and
- when it will be ready.
Extracting a why (a clear question of what must be solved) from what should be built is a critical point.
In the who category, Stein draws our attention to distinguishing actors (roles of potential users) from personae (archetypical instances of actors). Defining concrete use cases is invaluable. Stein also talks about scale of usage: how many people one might reasonably accommodate with a project varies (Simple Web Site: 1,000’s, Dynamic Web Site: 100’s, Voice, Video Chat, Virtual Classroom, 10’s). There are so many resources available that clarifying these categories of who as early as possible helps narrow your searches.
In the where category, Stein considers where we deploy the tool (online, desktop, mobile, kiosk) and where our audience uses the tool.
When largely addresses practical projections of project completion. The adage “underpromise, overdeliver” will surely come up as we all begin to plan our projects.
Links
I often find links in context too difficult to track. So I pulled Stein’s list into this ref-list and found pdfs of the broken links and seminal articles.
Blog posts about designing your personal development plan:
Jason Santa Maria’s post about fitting design into workflow (July 26, 2010)
Ethan Marcotte‘s Responsive web design (May 25, 2010) (he coined the term. RWD has changed dramatically since this article came out in 2010. Mashable called 2013 The Year of Responsive Web Design)
Alex Williams’s Risks/concessions of free software
Tom Kuhlmann approach to developing ELearning course
Older arguments about software development:
2005 post and comments about this instigating Nicholas Carr article
Fred Brooks’s 1986 article “No Silver Bullet – Essence and Accidents of Software Engineering” (FULL PDF) — Brooks talks about accidental and essential complexity (limit the first and acknowledge the second in developing software).
Jack Gordon and Ron Zemke trash the Waterfall Method, ADDIE or ISD Attack on ISD (Instructional Systems Design) (Training April 2000) (BROKEN LINK in Stein) — worthwhile read about how knowing the templated version of instructional systems design is not the most effective — a call for adaptability.
Klein’s Wikipedia glossary:
User-centered Design — his example Nielsen Norman Group
Useful Image:
Caption from JSM’s post: “The x-axis shows how true-to-browser rendering ranges from approximate to actual, while the y-axis depicts the scope of centralized control over layout and type from local to global. The sweet spot lies somewhere at the intersection of browser-like behavior for—and widespread control over—type and layout elements, while providing a fertile environment for creative thinking.”
Jason Santa Maria discusses how designing for mobile devices presents a remarkable degree of complexity when it comes to aligning software and hardware for the widest range of users. The toolkit he describes has certainly evolved, but the chart helps describe what you should consider when picking your tools.
Provocation and Motivation
Ok ITP Core 2. I’m ready to discuss. I was sitting with a DH friend who does history of science and had this week’s reading open on my computer. He was distressed to see the apocryphal NASA pen story as a point of entry into the questions of project development. The fact that this example so bothered him struck me as a problem central to what we are doing. Is it okay to use a tool that exists (in this case a popular and memorable example) simply because it is convenient and seems to work? Do we have a responsibility to find better solutions? We are going to have to make many concessions in the interest of time, but does this sort of shorthand of example teach us to be hasty or is it okay because its application and qualifications point to our understanding that the situation is deeper than we have time to address? As students of the humanities and social sciences coming to software development, we cannot expect to teach ourselves the components learned by people who focus solely on software development. As we all conceptualize our work in terms of basic components and get down to our nuts and bolts, I hope we can be conscientious as well as efficient. Perhaps I am over-optimistic, but I look forward to our collective attempts.
