[Humanist] 28.58 how digital projects end

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Wed May 28 01:18:12 CEST 2014


                  Humanist Discussion Group, Vol. 28, No. 58.
            Department of Digital Humanities, King's College London
                       www.digitalhumanities.org/humanist
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    Willard McCarty <willard.mccarty at mccarty.org.uk>          (15)
        Subject: how projects end

  [2]   From:    James Smithies <james.smithies at canterbury.ac.nz>          (14)
        Subject: RE:  28.55 how do digital projects end?

  [3]   From:    Matthew Kirschenbaum <mkirschenbaum at gmail.com>            (43)
        Subject: Re:  28.55 how do digital projects end?

  [4]   From:    Susan Brown <sibrown at ualberta.ca>                         (78)
        Subject: Re:  28.55 how do digital projects end?

  [5]   From:    "Prescott, Andrew" <andrew.prescott at kcl.ac.uk>            (43)
        Subject: Re:  28.55 how do digital projects end?

  [6]   From:    { brad brace } <bbrace at eskimo.com>                        (30)
        Subject: Re:  28.55 how do digital projects end?

  [7]   From:    Alberto Santiago Martinez <asmartinez at colmex.mx>          (33)
        Subject: Re:  28.55 how do digital projects end?


--[1]------------------------------------------------------------------------
        Date: Tue, 27 May 2014 08:49:26 +1000
        From: Willard McCarty <willard.mccarty at mccarty.org.uk>
        Subject: how projects end


Peter Galison's How Experiments End (1987) asks a somewhat different but
related question: not only how the wrapping up (sometimes calling to a halt)
is done by the experimenter but also about everything else that happens
around the ending of projects and what happens to their results, written and
constructed, afterwards. What happens to the ideas articulated in language
and embodied in code? And, of course, the question of why the ending:
because the objectives have been achieved? because the project ran out of
money, and why that happened? For us the focus on *initiatives*, on the new,
has not been entirely a good thing.

Yours,
WM
--
Willard McCarty (www.mccarty.org.uk/), Professor, Department of Digital
Humanities, King's College London, and Research Group in Digital
Humanities, University of Western Sydney



--[2]------------------------------------------------------------------------
        Date: Tue, 27 May 2014 02:17:32 +0000
        From: James Smithies <james.smithies at canterbury.ac.nz>
        Subject: RE:  28.55 how do digital projects end?


Hi Martin,

PRINCE2, developed for government purposes and widely used in the commercial world, does a good job of this. You can find handbooks in many university libraries, and there's information online too. The language can take a bit of getting used to, and I wouldn't recommend it for every project by any means, but the framework offers solid advice and asks to be tailored rather than offering a one-size-fits-all. The basic idea is that there's an art to closing a project properly (or even knowing when it's time to close it), just as there is to initiating and running one, and a range of activities that can be undertaken depending on size and scope. Some project managers specialise in closing projects, as it happens - it can take months with a large project, all in the interests of achieving as many 'benefits' as possible. 

I'm glad it's been raised on Humanist - it's a project phase that can achieve a lot with little expense, and could be used to introduce students to various aspects of technical project work. If anyone knows of advice in this area that's less oriented towards the government / commercial world I'd be interested to hear.

Regards,
James

Dr. James Smithies
Senior Lecturer in Digital Humanities
Associate Director, UC CEISMIC Digital Archive
University of Canterbury
DDI: +64 3 364 2896
http://dh.canterbury.ac.nz | http://ceismic.org.nz

-----Original Message-----
From: humanist-bounces at lists.digitalhumanities.org [mailto:humanist-bounces at lists.digitalhumanities.org] On Behalf Of Humanist Discussion Group
Sent: Tuesday, 27 May 2014 10:38 a.m.
To: humanist at lists.digitalhumanities.org

--[3]------------------------------------------------------------------------
        Date: Mon, 26 May 2014 22:57:46 -0400
        From: Matthew Kirschenbaum <mkirschenbaum at gmail.com>
        Subject: Re:  28.55 how do digital projects end?
        In-Reply-To: <20140526223758.EDA8E666A at digitalhumanities.org>


Hi Martin,

I edited a cluster of essays on this topic ("Done") in DHQ 3.2:

http://digitalhumanities.org:8080/dhq/vol/3/2/index.html

On Mon, May 26, 2014 at 6:37 PM, Humanist Discussion Group <
willard.mccarty at mccarty.org.uk> wrote:

>                   Humanist Discussion Group, Vol. 28, No. 55.
>             Department of Digital Humanities, King's College London
>                        www.digitalhumanities.org/humanist
>                 Submit to: humanist at lists.digitalhumanities.org
>
>
>
>         Date: Mon, 26 May 2014 10:30:41 -0700
>         From: Martin Holmes <mholmes at uvic.ca>
>         Subject: Existing work on bringing digital projects to a close?
>
> Hi all,
>
> I'm interested in learning about any previous published work which
> directly addresses the issue of how you bring a digital project to a
> definitive end. By this I don't mean the standard advice on how to
> choose data formats that have a good chance of long-term support, or how
> to get your metadata into central repositories; I'm interested in what
> happens, or what should happen, if you decide that you're done with a
> project and no more work will be done on it, and yet you want to do your
> best to ensure that the project itself (not just the texts or the data
> or the metadata, but also a web application that might run it, its
> history, its documentation and so on) might have a good chance of
> survival beyond the lifetime of the technologies and platforms on which
> it happens to run. Does anyone know of good work in this area?
>
> Best regards,
> Martin


-- 
Matthew Kirschenbaum
Associate Professor of English
Associate Director, Maryland Institute for Technology in the Humanities
(MITH)
University of Maryland
301-405-8505 or 301-314-7111 (fax)
http://mkirschenbaum.net and @mkirschenbaum on Twitter

Track Changes tumblr: http://trackchangesbook.tumblr.com/



--[4]------------------------------------------------------------------------
        Date: Tue, 27 May 2014 00:25:18 -0400
        From: Susan Brown <sibrown at ualberta.ca>
        Subject: Re:  28.55 how do digital projects end?
        In-Reply-To: <20140526223758.EDA8E666A at digitalhumanities.org>


Hi Martin,

The work by Bethany Nowviskie and Dot Porter on Graceful Degradation: 
nowviskie.org/Graceful_Degradation.pdf

Also Geoffrey Rockwell has a piece coming out from DHQ any time now on putting a large project to bed in an archive.

I think Trevor Munoz and Matt Kirschenbaum, among others, have also done considerable thinking about what it means to try to preserve an interface.

We just had a very good set of papers today that touched on many of these issues at the CSDH-SCHN conference at Congress 2014. I paste in the abstract below in case you'd like to contact any of the authors.

cheers,
Susan

The Lifecycle of Interfaces

Mauricio Bernardes, Ben Carroll, Lisa Cerrato, Luciano Frizzera, Mihaela Viorica Ilovan, Tianyi Li, Piotr Michura, John Montague, Geoffrey Rockwell, Laurentia Romaniuk, Stan Ruecker, Daniel Sondheim, Simone Sperhacke, Sarah Vela, Jennifer Windsor, INKE Research Group

E-mail: dosreisf at ualberta.ca, ilovan at ualberta.ca, tianyi2 at ualberta.ca, grockwel at ualberta.ca, lauren.romaniuk at ualberta.ca, sruecker at ualberta.ca, svela at ualberta.ca

Introduction

Stan Ruecker

This panel presents a selection of ideas arising from year 5 of the INKE project’s interface design team. As the project has progressed, we have become conscious not only of the larger context that is implied by the design and development of new knowledge environments, but also of the life cycles of those environments.

If we accept this biological metaphor, we can notice that it is not out of keeping with the spirit of long-running projects like Perseus to suggest that they have gone through a process of growth and articulation, much as we could expect of a natural autopoietic system. We therefore undertake to write the biography, not of the people involved in the project, but of the project as it has presented itself to the world through its interface. We can talk about memorializing it. We can examine the next points of possible articulation.

Elsewhere, our biological thinking leads us to consider hybridizing and splicing projects, perhaps, as with apple trees, to increase the variety of fruit that we can expect them to bear. However, with the metaphor comes another, perhaps less hopeful implication, namely that we must take care not to inadvertently introduce a kind of sterility through our experimentation.

Finally, we recognize that phases of projects, and in fact entire projects, can come to their ends, and ask what that implies in terms of documenting the history of the field.

1. The biography of an interface: Perseus Digital Library

Sarah Vela, Lisa Cerrato, Mihaela Ilovan, Tianyi Li, Geoffrey Rockwell, Stan Ruecker and the INKE Research Group

Unlike software preservation, the systematic documentation of user interface evolution is rarely talked about despite its historical and esthetical value, not to mention significance for future developments in the field of interface design.

As a case study in support of a curatorial strategy for interface design, we surveyed the evolution of Perseus Digital Library. We collected surviving images, programs and websites, and we interviewed Perseus staff to obtain background information for design and structure changes of the website/cd. The finds were then evaluated against the framework for the diachronic study of interfaces we proposed two years ago (Rockwell et al., 2011) and it was concluded that both internal and external factors guide the layout, features, imagery, and content of Perseus. These factors form a unique structure of synergy and compromise that is as indicative of Perseus’ interface as the design itself, and is especially valuable to study from a digital curatorship perspective.

2. CiteLens: splicing disciplines and visual models.

Mihaela Ilovan, Luciano Frizzera, Jennifer Windsor, Piotr Michura, Daniel Sondheim, Geoffrey Rockwell, Stan Ruecker and the INKE Research Group

Research, writing and referencing in the humanities differ significantly from those in the sciences (Hellqvist, 2009). Consequently, traditional citation analysis and its visualization methods (e.g. network maps), built on the assumption that all citation are equal, are inadequate in a humanist context. To bridge this gap, we designed CiteLens (Fig. 1) , a visualization tool for studying referencing and argumentation in humanist monographs (Ilovan et al., 2012).

Since CiteLens was conceived as the first visualization tool for the analysis of references in context, sources of inspiration for the development of a new visual paradigm were incorporated from two rather distinct fields: citation analysis and text analysis. This splicing of visual models and affordances led to the development of a tool, which - through its two-stage experience (i.e. “compare” and “contextualize”) - manages to transcend the borders of its parentage and to step into the realm of discourse analysis.

We explore this dynamic of interface hybridization and present the results of our initial case study, which highlights CiteLens's potential for the hermeneutical exploration of humanist writings.

3. Growth and Multiplication: Designing for the Mobile Generation of Perseus

Laurentia Romaniuk, Lisa Cerrato, Mihaela Ilovan, Ben Carroll, Geoffrey Rockwell, Stan Ruecker, and the INKE Research Group

This project is a collaborative effort between INKE and the Perseus Digital Library (Perseus) to explore the development of a mobile optimized tool for a digital library characterized by expansive collections and a user-base that spans various demographics including age, location, native language, and connectivity to the internet. With the number of individuals choosing to access the Internet primarily through mobile devices on the rise (Rainie, 2012), INKE and Perseus recognized the opportunity to develop a web presence for Perseus that would address increased mobile use. An initial usability study of Perseus as it relates to web and mobile use was undertaken. Based on the findings of this study and informed by a review of emerging trends and technologies in mobile application design, the INKE team has developed preliminary designs for two mobile tools to address Perseus’ needs.

4. Structured Surfaces for Digital Board Games: The DH Experience

Luciano Frizzera, John Montague, Simone Sperhacke, Maurício Bernardes, Geoffrey Rockwell, Stan Ruecker and the INKE Research Group.

The process of modeling workflow (Fig. 2) for editorial purposes might be seen as a laborious and tedious experience. The interactive nature of our Visual Workflow Interface tool (Frizzera et al, 2012) can easily be transformed into a ludic environment. We propose incorporating the affordances of board games into the current tool iteration, creating a cooperative game based on the work of DH practitioners.

The prototype game that we have developed models the experience of researching and publishing in a collaborative, multi-disciplinary academic environment. As Gee argues, games offer “players continual opportunities to learn, solve problems, and become more skilled” (Gee, 2005, p. 29). By mutating our work tool into a game platform, we are offering a method of serendipitous discovery; while enjoying the game, people are prone to critically explore the process of modeling, which could lead to new insights about knowledge construction.

5. Where Do Good Interfaces Go When They Die: Preserving Perseus Interface History

Tianyi Li, Mihaela Ilovan, Laurentia Romaniuk, Lisa Cerrato, Geoffrey Rockwell, Stan Ruecker and the INKE Research Group

With many of the digital structures created disappearing over time (Day, 2006), both content and interface become to some extent invisible and inaccessible. There are preservation challenges for physical cultural artifacts, and some of these are shared with digital cultural artifacts: it is important in both cases, for instance, that the content, the substance, be preserved. For the preservation of user interfaces, however, the focus is on visual and interactive features instead of content, and appearance and interaction are highly contingent.

The proposed paper describes a collaborative model to document, archive and possibly exhibit the evolution of the Perseus Digital Library interface. In order to document not only the look of Perseus but also the feel of it (i.e. the user experience), we are collecting along with web pages from major versions of the project, screencasts of user interaction and additional documentation such as user manuals, ephemera and grant proposals. The metadata model created is adapted to the particularities of an interface archive and, together  with the types of content included, opens a conversation on the preservation of digital design.

Conclusion

Geoffrey Rockwell

In this panel we use the metaphor of “lifecycle” to draw attention to change in interfaces and how little we know about studying change and managing it. The metaphor also suggests that interfaces are living things - that they are autopoietic or able to fashion themselves. This is clearly not true. Interfaces are abstractions that don’t exist except between us and computers. We fashion interfaces and fashioned the very idea. The idea is useful, but also limiting as it is tied to the screen as the site of interaction. Ideas too have a lifecycle. Now, as we move from developing interfaces to making interactives the time has come to consider an end to interface.

References

Day, M. (2006). The long-term preservation of Web content. In Web archiving (pp.177-199). Springer Berlin Heidelberg.

Frizzera, L., Radzikowska, M., Roeder, G., Pena, E., Dobson, T., Ruecker, S., Rockwell, G, Brown, S., The INKE Research Group. (2013). Visual workflow interfaces for editorial processes. Literary and Linguistic Computing, 28(4), 615–628. doi:10.1093/llc/fqt053

Gee, J. P. (2005). Why video games are good for your soul: pleasure and learning. [Melbourne, Vic.]: Common Ground Publishing.

Hellqvist, B. (2009). Referencing in the humanities and its implications for citation analysis. Journal of the American Society for Information Science and Technology, 310–318. doi:10.1002/asi.21256

Ilovan, M., Frizzera, L., Michura, P., Rockwell, G., Ruecker, S., Sondheim, D., Windsor, J., and INKE TEAM. (2012). Exploring humanist citation practice through visualization. Presented at the SDH-SEMI, Waterloo, Canada.

Rainie, L. (2012). Tablet and e-book reader ownership nearly double over the holidaygift-giving period. Retrieved from http://www.pewinternet.org/Reports/2012/E-readers-and-tablets/Findings.aspx

Rockwell, G., Ruecker, S., Ilovan, M., Sondheim, D., Radzikowska, M., Organisciak, P., & Brown, S. (2011). The Interface of the Collection. Presented at the Digital Humanities, Stanford.

On May 26, 2014, at 6:37 PM, Humanist Discussion Group <willard.mccarty at mccarty.org.uk> wrote:

>                  Humanist Discussion Group, Vol. 28, No. 55.
>            Department of Digital Humanities, King's College London
>                       www.digitalhumanities.org/humanist
>                Submit to: humanist at lists.digitalhumanities.org
> 
> 
> 
>        Date: Mon, 26 May 2014 10:30:41 -0700
>        From: Martin Holmes <mholmes at uvic.ca>
>        Subject: Existing work on bringing digital projects to a close?
> 
> Hi all,
> 
> I'm interested in learning about any previous published work which 
> directly addresses the issue of how you bring a digital project to a 
> definitive end. By this I don't mean the standard advice on how to 
> choose data formats that have a good chance of long-term support, or how 
> to get your metadata into central repositories; I'm interested in what 
> happens, or what should happen, if you decide that you're done with a 
> project and no more work will be done on it, and yet you want to do your 
> best to ensure that the project itself (not just the texts or the data 
> or the metadata, but also a web application that might run it, its 
> history, its documentation and so on) might have a good chance of 
> survival beyond the lifetime of the technologies and platforms on which 
> it happens to run. Does anyone know of good work in this area?
> 
> Best regards,
> Martin




--[5]------------------------------------------------------------------------
        Date: Tue, 27 May 2014 08:12:42 +0000
        From: "Prescott, Andrew" <andrew.prescott at kcl.ac.uk>
        Subject: Re:  28.55 how do digital projects end?
        In-Reply-To: <20140526223758.EDA8E666A at digitalhumanities.org>


There was a cluster of three articles in a special issue of Digital Humanities Quarterly 3.2 (2009), edited by Matt Kirschenbaum, called ‘Done: Finishing Projects in the Digital Humanities’: http://www.digitalhumanities.org/dhq/vol/3/2/index.html. These explore the tensions between the managerial and administrative pressure to ‘finish’ a project and the need for continuing input to sustain the content. I personally have a lot of sympathy with the view expressed by William Kretzschmar in the DHQ cluster and elsewhere that the long-term curation of such projects is an important future role of the library.

Andrew
 
Professor Andrew Prescott FRHistS 
Head of Department 
Department of Digital Humanities 
King's College London 
26-29 Drury Lane 
London WC2B 5RL 
@ajprescott 
www.kcl.ac.uk/artshums/depts/ddh 
digitalriffs.blogspot.com 
+44 (0)20 7848 2651 

On 26 May 2014, at 23:37, Humanist Discussion Group <willard.mccarty at mccarty.org.uk> wrote:

>                  Humanist Discussion Group, Vol. 28, No. 55.
>            Department of Digital Humanities, King's College London
>                       www.digitalhumanities.org/humanist
>                Submit to: humanist at lists.digitalhumanities.org
> 
> 
> 
>        Date: Mon, 26 May 2014 10:30:41 -0700
>        From: Martin Holmes <mholmes at uvic.ca>
>        Subject: Existing work on bringing digital projects to a close?
> 
> Hi all,
> 
> I'm interested in learning about any previous published work which 
> directly addresses the issue of how you bring a digital project to a 
> definitive end. By this I don't mean the standard advice on how to 
> choose data formats that have a good chance of long-term support, or how 
> to get your metadata into central repositories; I'm interested in what 
> happens, or what should happen, if you decide that you're done with a 
> project and no more work will be done on it, and yet you want to do your 
> best to ensure that the project itself (not just the texts or the data 
> or the metadata, but also a web application that might run it, its 
> history, its documentation and so on) might have a good chance of 
> survival beyond the lifetime of the technologies and platforms on which 
> it happens to run. Does anyone know of good work in this area?
> 
> Best regards,
> Martin




--[6]------------------------------------------------------------------------
        Date: Tue, 27 May 2014 04:30:35 -0700 (PDT)
        From: { brad brace } <bbrace at eskimo.com>
        Subject: Re:  28.55 how do digital projects end?
        In-Reply-To: <20140526223758.EDA8E666A at digitalhumanities.org>





... they _never end!

[see attached 12hr-file]

/:b

*** Attachments:
    http://www.digitalhumanities.org/humanist/Attachments/1401190621_2014-05-27_humanist-owner@lists.digitalhumanities.org_25605.1.txt

On Tue, 27 May 2014, Humanist Discussion Group wrote:
>
>         Date: Mon, 26 May 2014 10:30:41 -0700
>         From: Martin Holmes <mholmes at uvic.ca>
>         Subject: Existing work on bringing digital projects to a close?
>
> Hi all,
>
> I'm interested in learning about any previous published work which
> directly addresses the issue of how you bring a digital project to a
> definitive end. By this I don't mean the standard advice on how to
> choose data formats that have a good chance of long-term support, or how
> to get your metadata into central repositories; I'm interested in what
> happens, or what should happen, if you decide that you're done with a
> project and no more work will be done on it, and yet you want to do your
> best to ensure that the project itself (not just the texts or the data
> or the metadata, but also a web application that might run it, its
> history, its documentation and so on) might have a good chance of
> survival beyond the lifetime of the technologies and platforms on which
> it happens to run. Does anyone know of good work in this area?
>
> Best regards,
> Martin


--[7]------------------------------------------------------------------------
        Date: Tue, 27 May 2014 15:29:49 +0000
        From: Alberto Santiago Martinez <asmartinez at colmex.mx>
        Subject: Re:  28.55 how do digital projects end?
        In-Reply-To: <20140526223758.EDA8E666A at digitalhumanities.org>


If i understood your question correctly you are asking about project development.  Within the field of computer systems development and project management, a system project doesnt end since the models proposed are typically concieved in a cyclical fashion.  So what might be interpreted as the "end"  is a transition into the maintenance phase.  A system can be maintained only for so long before it becomes obsolete and can no longer be maintained after which the system then needs to be redeveloped.  I think the same goes for the digital objects and of course an intention to always try and better the system.  In this respect you can look for literature related to the systems development lifecycle in which various authors propose a series of models.

Sent from my iPhone

> On May 26, 2014, at 5:38 PM, "Humanist Discussion Group" <willard.mccarty at mccarty.org.uk> wrote:
> 
>                  Humanist Discussion Group, Vol. 28, No. 55.
>            Department of Digital Humanities, King's College London
>                       www.digitalhumanities.org/humanist
>                Submit to: humanist at lists.digitalhumanities.org
> 
> 
> 
>        Date: Mon, 26 May 2014 10:30:41 -0700
>        From: Martin Holmes <mholmes at uvic.ca>
>        Subject: Existing work on bringing digital projects to a close?
> 
> Hi all,
> 
> I'm interested in learning about any previous published work which 
> directly addresses the issue of how you bring a digital project to a 
> definitive end. By this I don't mean the standard advice on how to 
> choose data formats that have a good chance of long-term support, or how 
> to get your metadata into central repositories; I'm interested in what 
> happens, or what should happen, if you decide that you're done with a 
> project and no more work will be done on it, and yet you want to do your 
> best to ensure that the project itself (not just the texts or the data 
> or the metadata, but also a web application that might run it, its 
> history, its documentation and so on) might have a good chance of 
> survival beyond the lifetime of the technologies and platforms on which 
> it happens to run. Does anyone know of good work in this area?
> 
> Best regards,
> Martin






More information about the Humanist mailing list