Scalar demo with Paige Morgan

Paige began by discussing the historical lack of funding for graduate students working on DH projects, and the step forward that the DH Commons grant represents. She also provided an example of what might be considered a manageable set of goals for a project, using her own current task list for her project, Visible Prices. Paige emphasized the importance of identifying specific tasks that work towards the completion of a project, rather than imagining that you will build an entire project in the period of three months.

She proceeded to discuss Scalar,  a content management and sharing platform developed at USC and currently in open beta, the use of which is encouraged as a component of projects for DH Commons. The content of Paige’s remarks on Scalar is currently visible on in her own Scalar site, under the Navigating Visible Prices path.

Scalar is a tool built for humanities specialists who may not have a great deal of technological literacy. It is an open-access platform, currently in open beta. This means that the documentation may not be as thorough as it would be for a product that has been through a full release cycle, and that development is still in process. Beta users are the final group of testers, and are requested to report issues.

A question was raised about backwards compatibility in later iterations; Paige said that USC had told her they are working on that, but that it would be a good question to continue to raise in Scalar webinars. She pointed out that there is currently no data export function, which would be needed in case the platform were abandoned, although she also noted that it is a well-funded project and unlikely to go away any time soon. Paige reiterated the availability of Scalar webinars with Micha Cardenas, one of the project leads, and noted that she arranges public space at UW for groups to attend these.

Scalar can be found at scalar.usc.edu/works.

Scalar is modeled on blogging in terms of ease of usability and publishing, but rather than defaulting to a temporal content arrangement, it requires the users to make decisions about how readers should traverse the data. This means that a user needs to understand what basic unit of information he or she is working with, and what that data looks like. Scalar users make connections between their data elements by tagging data units, but need to decide whether it is more important to represent the full complexity of that network, or to sacrifice a certain level of complexity in favor of ease of navigation. This is user decision, and there is not correct answer. The platform attempts to mediate between these poles by allowing users to create paths by which readers move through the data.

The basic element of Scalar is the page, and visualizations are created by user-defined relationships between these pages. For another useful write-up on working with Scalar, see this PCMag review, which provides a fairly detailed user narrative of figuring out how the platform works.

Scalar is particularly useful as a way to import and annotate multimedia artifacts, and partnerships exist with several archives to facilitate this. However, this can bring up issues of fair use, particularly when texts (broadly defined) from other sources are used. This is a complex issue, and a conversation with specialists at UW Libraries is recommended.

Q&A with fellowship committee members Tyler Fox, Brian Reed, and Kathleen Woodward

Those in attendance introduced themselves. Graduate students and faculty from: Information School, Spanish-Portuguese, English Department, Geography, Women’s Studies–Gender and Sexuality, and Germanics

Note that the grant is for Faculty and PhD candidates; graduate students who have not advanced to candidacy by November 15, 2013 are ineligible to apply for this year’s grant.

The application requires a project narrative; applicants can look at successful narratives on the NEH site, as well as the FAQ on Paige’s Visible Prices site for examples of what to include.

Successful projects will have a defined scope accomplishable in the time allotted. They will have a clear audience(s) in mind, with consideration given to more public audiences. Projects may involve using digital tools to study or critique digital culture, in addition to the more traditional “building something.” Remember that pedagogy is also scholarship! A DH project might involve the critical analysis of technology, not just one that uses some kind of digital tech to produce scholarship. Projects should seek to critically analyze these tools as ones that use them.

The scope of the full project may be quite broad, but applicants should think carefully about what is achievable with the time and resources that the grant allows; proposals should be clear about the iteration that the grant will support, as well as contextualizing that work within the larger project. For graduate students, this project is not something that you want to be working on for the next five years, but it may be a component of a larger project.

Most work that we do as academic occurs in stages, so many of those projects are fictions because they have yet to be completed. We are and should be thinking about what we are doing five years from now, two years from now, six months and next week. Thus your proposal will be a fiction that might change once it starts. However, the main thing to focus on is the scope–is it realistic for a summer project.

Projects should support dissertation work, but need not (and should not) actually be the dissertation itself. Make this connection clear in your application.

Regarding copyright issues, make sure that you consult sources like critical commons, and research the fair use rules when it comes to your sources. It might be a good idea to have that information squared away before you write your proposal. Maybe include a letter or some form of evidence that you have already or are in the process of requesting permission for use.

Research funds for the grant can be used for many things – : if have done most of the work prior to the summer, you can use the funds for travel for professional development or for design improvements to your project. You cannot, however, use the funds to purchase hardware (e.g., new laptop)

Those applying as faculty/graduate student teams will need to consider how to allocate funding. If you apply as faculty and plan to work with graduate students, be aware of the graduate student union bylaws regarding compensating grad students for their labor. You might consider looking for RA funding internally if you wish to team up with graduate students.

Think about your own skills and abilities, as well as what you might need to learn or contract out.

Articulate the developmental stage of your project. Is it just beginning, or clearly developed? The application process is not biased to a particular stage, but applicants are expected to understand and communicate the developmental cycle of their work.

Your project need not be a public scholarship project, but you should be clear about your plans for fulfillment and dissemination.

Scalar is encouraged so that fellowship cohort can help and troubleshoot for one another, but is not a requirement.

Application information for graduate students can be found here, and faculty information here. Applications are due November 15, 2013.