Navigation:
Documentation
Archive



Page Tree:

Child pages
  • Unsustainable Tools

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

Unsustainable Tools

Definition

This theme has been merged into Changing Technologies and Unsustainable Tools and is now closed for edits. Please make any further changes on that theme's page.

A theme emerged in several Workshop One discussions around the challenges facing software tools that have been created for arts and humanities research. Comments indicated a real lack of sustainability for such tools (in the broadest sense, including the lack of support systems for using tools), based on the experiences of workshop participants. (Many references are included here to illustrate a number of important points.) Some of the challenges highlighted include:

  • How to discover and share tools - matching tools to needs
  • Limits to the reuse of tools
  • Impermanence of projects, of programmer continuity, and of technologies
  • Locality, uniqueness, niche-only, one-time nature of tools - not generalized
  • Un-maintainability, obsolescence - of tools themselves and of the underlying hardware/software and operating systems environments
  • Orphans created by waning interest or energy of the creators or scholars who commissioned the tools originally
  • Short-lived solutions
  • Learning curve issues and technophobia on users' parts
  • Actual utility of the tools
  • Lack of documentation and support
  • Methodological concerns, biases, drawbacks in using tools
  • Abstraction away from the authentic (objects of study)
  • Narrow scope and applicability
  • User friendliness and usability concerns
  • Recurring maintenance costs
  • Appropriateness to user needs
  • Challenges of preserving context and dealing with ambiguity
  • Need to generalize
  • Preserving investment in data and analysis work if abandon a given tool
  • Need continuity of use.

All of these signal areas for Project Bamboo architects and designers to heed to avoid repeating challenges of past efforts.  Mellon seeks sustainability in this project, and that goal applies to the shared technology services that Bamboo intends to produce.

Related to this theme are some comments from the report of the September 2005 Summit on Digital Tools for the Humanities (http://www.iath.virginia.edu/dtsummit/SummitText.pdf) held at the University of Virginia.  Observations on pages 16-17, copied below, further illustrate challenges from generalized tools, and then offer some suggestions for ways that Bamboo can address challenges of sustainable tools.

By consensus, the group divided such tools into two categories. The first category is not specific to humanistic research, but includes tools that ride the technology wave and appear to serve a very general audience. ...  These tools are certainly valuable and are heavily used by scholars as well as business and personal users. Academic or research applications may be secondary to commercial applications, however, so the scholarly community cannot expect tool designers to cater to its particular needs. Indeed, the ebb and flow of development of these tools is more likely to be driven by market forces and popular interests.  [page 16]

A scholar operating in an environment populated with digital data resources channels her scholarship in her choices and uses of her tools, such as mark-up, database structure, interfaces, and search engine. The scholarly environment has become more technical, and the quality of the work produced is influenced by decisions that are of a technical nature. This requires that the scholar understand the function as well as the limitations of the tools selected. Many tools must be tailored to particular uses. That is, the user determines and sets parameters to control what results are returned. A simple example is the search engine. Advanced search parameters permit the user to specify what a search returns, so that the user is not overwhelmed with irrelevant or superfluous items. However, the user also needs to be able to predict what will not be returned as results, so that blind spots do not emerge.

Because these tools are just emerging and are evolving rapidly, participants concluded that the most valuable aid for collaboration would be a clearinghouse to inform and educate digital scholars about useful tools. Specifically, they would like to see a forum for evaluating when and how a tool is usefully wielded and what undocumented bugs the tool might exhibit in its functioning. This would include a careful description of each tool and a URL link to the tool's host site; the creator's vision of the tool; related software tools, resources, and a list of projects which use that tool; and rich indexing and categorization of tools listed in the clearinghouse or repository.

To be even more useful, site content could be subject to a quality control process, which might include peer review of tools that are listed, as well as in-depth objective analyses of the pros and cons of the tool for various applications and necessary level of maintenance. Competitive tools in a category should be rated fairly against one another on several dimensions. The site should also provide relevant facts, such as dissemination history, pointers to full documentation, objective descriptions of uses by other scholars across multiple disciplines, statistics on adoption, and published results that cite the tool's use.

This kind of a clearinghouse would require long-term funding support. However, it would be a useful mechanism for funding agencies to learn what tools are more productive, how they are being used, who uses them, and what tool functionality is still needed.

Participants also felt that there should be follow-up conferences and outreach meetings to discuss the issues related to digitally enabled collaboration. These conferences should include both those who fund tools and those who use them (e.g., graduate students, post doctoral fellows, and rising and established scholars). Outreach meetings could expand the digital scholarly community and target those who are reluctant or ill-equipped to take advantage of new technologies.  [page 17]

 

Name(s)

Institution(s)

Proposed/originated by:

Jim Muehlenberg

Univ. of Wisconsin, Madison

Current facilitator(s)

Facilitator_Name_Here_(optional)

Facilitator_Institution_Here_(optional)


Back to Identify Themes page...


What tools, standards, organizations, or efforts exist in this area of scholarly practice?

Item

Description - what is it?

URL or other reference

sound_byte_name_or_description (your_name)

summary_description (your_name)

http://www.interesting_thing.org


What tools, standards, organizations, or efforts are missing from this area of scholarly practice?

Item

Description - what is it?

URL or other reference

sound_byte_name_or_description (your_name)

summary_description (your_name)

http://www.interesting_thing.org


What part of this area of scholarly practice is within Project Bamboo scope, and why?

Item

Description - what is it?

Why is it in scope?

sound_byte_name_or_description (your_name)

summary_description (your_name)

explanation_of_why_in_scope (your_name)


What part of this area of scholarly practice is outside Project Bamboo scope, and why?

Item

Description - what is it?

Why is it out of scope?

sound_byte_name_or_description (your_name)

summary_description (your_name)

explanation_of_why_out_of_scope (your_name)


References

References (e.g., material from Workshop 1 notes or flipcharts)

Contributor

  • Coordinating logistical support for hardware used in research.  There is a ton of work getting the HW to work that they are using in their research.  This is often not well represented in the grant budget, and involves lots of chasing around to find right resources, as well as lots of fiddling to get things working. (Ex. 2 scribe notes, 1a-C)
  • Modularization of tools for exchange with others.  Package, to make simpler for another user.  Need wrappers into software & need to be extracted so don't have to reauthor again. Software extraction, to prevent unnecessary reauthoring.  (Ex. 2 scribe notes, 1a-E)
  • Is there sufficient information to use tools?  As a user, can you find the tools, and is there enough information to use them? ... Know what tools are available, so can put needs in contact with tools. ...  Biggest challenge is sustaining technology.  (Ex. 2 scribe notes, 1c-A)
  • How would I put someone in touch with these tools?  At the moment, they're not well-documented, which is the purpose of surveys.  Happens in the context of a project, and then disappears.  One of key issues? How to keep these tools from being lost after the project dies?  (Ex. 2 scribe notes, 1c-B)
  • Built TextGarden, allows it to be done; probably very few people have heard of it (local institutions, local tools, local faculty interest) - programmer left 6 years ago, probably no one uses that programming anymore.  How do you create something that can survive the loss of the programmer?  Humanists need very specialized things, so you build the tool - hard to sustain, maintain, make available more broadly.  Tend not to do these one-off projects anymore; don't have the resource or know that in three years, we won't be able to go into the code and changes.  Would have to keep old computers around to use them; they were very beautiful when they were done.  Scholars' interest tends to wane over time, too - lots of "orphan works" that still have some potential value.  Limited resources, we're not thinking 30 years down the road -1-2 years.  How do you embed works in a structure that will survive the loss of a  scholar/programmer.  Tend to use all the features of version X.X because scholars want to do complicated things; these are very vulnerable to software change.  You don't realize how valuable it is; something dies, and suddenly you start getting emails. ... Providing at the data level a way to deal with that; the next phase is generalizing the tools, having a community base so they don't become obsolete. ... With other things, when I don't have the energy to sustain it, there's a community that can pick up the slack.    (Ex. 2 scribe notes, 1d-A)
  • Tension between common denominator approach vs. building sophisticated tools. Technologies, organizations, faculty with specific needs vs. trying to build common infrastructure for broad use. ... How to avoid the tyranny of the database?  Databases involve overhead.  Time to create machine readable database often not worth it unless you have canonical texts. What do databases do well?  What constraints do they impose? not sure the database is "the solution" for all kinds of problems.  (Ex. 2 scribe notes, 1d-F)
  • S1 have built large database of social science data; 5 year project. For social science scholars, but also for the public. Funding has run out, can't find funding to continue; "on life support" through library. Katz's law, "costs more to maintain a database than to build it." D2 confront this a lot. Get funding to build something, scholars come to rely on it, but when funding runs out, isn't clear how that it will be supported over time. ... H1 new medium is somewhat threatening because research used to be a solo activity.  Now have to work with technology people, etc. Threatening to the way we've been trained to work for 40 years.  (Ex. 2 scribe notes, 1d-G)
  • Does technology introduce bias?  Does the algorithm/data source mess you up? ... Difficulty barrier for tools.  (Ex. 2-3 flipcharts, 1c-A)
  • Tools don't care.    (Ex. 2-3 flipcharts, 1c-B)
  • Can digital representation replace/not replace raw data/experience? ... Do tools integrate/are interoperable?  (Ex. 2-3 flipcharts, 1c-E)
  • Sustain technologies.  Fund "open source"  (Ex. 2-3 flipcharts, 1c-G)
  • Build text analysis software (ex.: TextGarden) (written in small print in pen).  One-off, not well known outside Princeton.  Programmer left; "dead" programming language.  Hard to generalize specialist tools.  Sustainability a huge issue for work that was "beautiful" in its time (orphaned works). Scholars' interest wanes too (orphaned works).  No mechanism to keep specialty software/sites alive beyond a short period of time. (Ex. 2-3 flipcharts, 1d-E)
  • Unique tools for single product vs. larger/scalable tool.  How to solve for re-use next year?  Work on disconnect between how we build and how user will use it.  Humanist - expertise works against kinds of tools we're building.  Can we build tools to support humanist inquiry - therefore extremely flexible?  (Ex. 2-3 flipcharts, 1d-G)
  • IT identifying common needs/shared solutions.  (Ex. 2-3 flipcharts, 1d-I)
  • Built into infrastructure - disagreement part of practice.  Humanist study is contextual (science de-contextual).  Ambiguity.  Interpretation as core practice in humanities.  How to represent (????????).  Challenge to tool building.  [Another] Challenge for tool building - Generalizable tools.  Exit strategies - code - needs to be commented.  Challenge for tools built for continual use.  (Ex. 2-3 flipcharts, 1d-K)
  • Grad students are more interested in databases and such tools, whereas undergrads snub such "old fashioned" digital tools more readily.  Techie - Fuzzy divide will persist for a while ... How to prevent digital humanities scholars from becoming ghettoized within their disciplines?  Perhaps if enough was digitized, gravity would attract those who are not interested now in digital tools.  (Ex. 6a scribe notes, 1a-E)
  • D7: In a hiring process re: social implications of communication technologies, seeing grassroots (as opposed to top-down) communications technology awareness in younger candidates for hire.  D7 himself is a "holdout for old technologies" (for quality reasons ... sound, video, etc. ... there are limitations in quality, possibility of obsolescence to digital technologies) even though he sees the value of converting to digital for archival, sharing, etc. purposes; yet he is impressed with younger students' methods of going out into the field and getting information that can be disseminated immediately.  D7 is "learning to be bi-technical." Each has a value.  D8: Persistence of older technologies is something Bamboo should take into account. D3: realizes she needs to attend to both digital and non-digital archival concerns. ... D5: Newer (IT) staff are more adept at agile development, mashups ... whereas older staff have a grounding in persistence, robustness, data management, data curation. (Ex. 6a scribe notes, 1b-B)
  • P1: would like to see incoming grad students be put through boot camp in fields important to them; learn what resources library provides for those fields; concerted effort by librarians across insts. who work in same fields to build dynamic (drupal) research portals rather than static pages; goal is to bring people up to speed on tools already available.    (Ex. 6a scribe notes, 1d-E)

Jim Muehlenberg

Back to Identify Themes page...