end/line — Week 1

For the encoded poetry project (now known as end/line), I’ve been assigned as the main back-end developer. I do have a lot of experience in this role in both professional and personal projects, so I’m hoping I’ll be able to bring in some expertise and explore with new technologies and ways of thinking that will fit this project.

My first order of business is to determine exactly what technologies I’m going to need to use. I don’t think anything super extravagant is going to be needed, especially with regards to the server everything will be hosted on and the frameworks associated with it. For the beginning of the project, it’s important to have an environment that works and is secure, and that’s why I’m opting to use third-party infrastructure. Of course, that can lead to problems if the third-party infrastructure breaks. That’s actually happening right now with AWS and all my sites are down (and I’m sure a lot of others). But I think it’s worth the risk.

In my view, the technologies and languages associated with the back-end should be as modern as possible. The goal is for end/line to continue beyond the end of this semester and using modern technologies from the start will help it to stay up to date. Below is a list of a few of the languages/frameworks I plan to use.

-JavaScript (language all around)

-Node.js (server-side language)

-Express (server-side framework)

-PostgreSQL/MongoDB (database)

I’ve made these choices (as opposed to Linux/Apache/MySQL/PHP) to allow for a simple, easily-maintained, and modern back-end design. I’ve chosen these specific frameworks and languages because this project doesn’t require the use of Python scripts, which would benefit from having a Django framework, and definitely doesn’t require the intensity and thoroughness of a Ruby on Rails framework. The database will either use the classic SQL-based PostgreSQL or the NoSQL-based MongoDB. That choice will be made after consultation with the team.

The biggest part of end/line and the most challenging for me is going to be the back-end XML parsing and validation. The front-end will offer the ability to create it, but it is up to me to validate it and eventually add it to the database. This will require a reusable script that will need to be run on an XML input. It will either need to return a confirmation of success or specify exactly where the errors are. How that will look is still to be determined.

My plan for building this is to really learn how XML works (I don’t use it at all) and start devising ways to build the script. I will also need to work with the front-end developers on how they plan to build the text editor and how exactly they will send its output to the back-end. There will be a lot of opportunities for the group and myself to learn how a front-end-to-back-end workflow works for this project.

While I don’t have a stake in the poetry side of this project, I’m interested in the technological aspects. There is a lot of room for me to leverage what I already know and add some new technologies that I don’t that I feel like will work with this project.

I’m looking forward to seeing how this team will work together. I have a lot of confidence in everyone in the group and their ability to put something together that works really well, and I feel like the end product is going to be better than what we think it will be now. I always have a lot of fun building digital projects and I don’t think this will be any different.

Posted in Uncategorized | Comments closed

Resources again

Hi Spring Praxis people,

I wanted to do another post giving you information about upcoming workshops and useful guides.

I highly recommend you attend tonight’s collaborative tools workshop, 6:30 – 8:30 in room C201 (concourse!) and tomorrow’s Social Media Fellows’ workshop on Tweeting, 6:30-7:30 in room 5414.

Because both teams are working with text — and you will need to clean your data and metadata — I also recommend attending this Thursday’s Text Analysis Working Group, Thursday, March 2nd, from 12:30pm – 2:00pm, in room 7414. Sign up here.

Good to remember: Office Hours are Tuesdays 2-4pm. PUG meets Wednesdays 12-2pm.

Email [email protected] with questions!

-Jojo

Resources again.

In the fall I posted about various workshops and blog posts that might help you or point you to further resources. Now might be a good time to revisit these. Now that you have clearer project objectives, you might find the DESIGN or WEB DEVELOPMENT sections more helpful. It may seem like inundation, but using these short pieces may help you learn from other people’s work.

MORE RESOURCES? YES. MORE.

Hi #DHPraxis16!

Welcome to this nifty table I made of blog posts, handouts, workshop outlines, and tutorial slide decks created by GC Digital Fellows! I broke the posts down into some umbrella categories.

  • data and databases
  • design
  • mapping
  • programming (including python)
  • project management
  • projects
  • text analysis
  • web development

If you are still coming up with your dataset — check the first category!

If you are past that and know what you want to do — check out mapping or text analysis or programming!

If you now want to put your project on the web– check out web development and if you want it to look nice– try design!

These resources are good starting places– content ranges from pretty basic to more advanced. (I recommend Getting the Most out of a Humble Technology: Word Search).

Good luck, and remember — Digital Fellow Office Hours are Tuesdays 2-4.

DATA and DATABASE RESOURCES

Intro to Data Cleaning and Visualization Tools Handout A.L. McMichael
Linking Outside the Box (Linked Data for the Uninitiated, Part 2) A.L. McMichael
Linked Data for the Uninitiated (Part 1) A.L. McMichael
The mostly non-STEM guide to data literacy Hannah Aizenman
data debugging Workshop Outline Hannah Aizenman
Finding Digital Archives Jeff Binder
Digital Tools for Qualitative Data Analysis Patrick Sweeney
Organizing Image Collections handout A.L. McMichael
data visualization Workshop Outline Hannah Aizenman
Fun Times with SQLite! Or, a Beginner’s Tutorial to Data Management and Databases with SQL Ian Phillips
SQLite Ian Phillips
Databases for Smart People Who Are Scared of Databases Keith Miyake

DESIGN RESOURCES

DH and Design A.L. McMichael
A Crash Course in Digital Photo Editing A.L. McMichael
Introduction to Image Editing Handout A.L. McMichael
Illuminating the Challenges of Web Design Laura Kane

MAPPING RESOURCES

Treebanking with Arethusa Jeremy March
Intro to Mapping with CartoDB Keith Miyake
Learning to Map with ArcGIS StoryMaps Keith Miyake

PROGRAMMING RESOURCES

On Choosing a Mobile Platform in the Digital Humanities Jeremy March
Set up a development environment Evan Misshula
Python 2 Tutorial Evan Misshula
iOS Jeremy March
Intro to the Command Line Keith Miyake
Python workshop Michelle McSweeney
Speaking of ‘Speaking in Code’ (Part 2) Micki Kaufman
Speaking of ‘Speaking in Code’ (Part 1) Micki Kaufman
Python resources Patrick Smyth
Programming with Python workshop materials Patrick Smyth
Python resources Patrick Smyth
Python Workshop Outline Patrick Smyth
https://digitalfellows.commons.gc.cuny.edu/2015/10/15/how-to-python/ Hannah Aizenman

PROJECT MANAGEMENT RESOURCES

Github Mary Catherine Kinniburgh
Evernote Guide Erin Glass
project management, or, your hand is not your dayplanner Erin Glass
Research Management Tools Keith Miyake
Getting started on github Patrick Smyth
“Research Management” handout Erin Glass

PROJECTS

Tool refresh: a crash course Erin Glass
Turning an idea into a tool Erin Glass
MEDIA RES #2: NYC DH Lightning Talks Erin Glass
Is this what reading looks like? Erin Glass
Your Most Valuable Resource…People! Ian Phillips
The Complexity of Machine Writing Jeff Binder
Teaching Ancient Greek with iOS and Android Jeremy March
The Contours of Community: Recap of “CUNY DHI, Building a DH Community” Lightning Talks Mary Catherine Kinniburgh

TEXT ANALYSIS

Getting the Most out of a Humble Technology: Word Search Jeff Binder
Text Analysis with MALLET Michelle McSweeney

WEB DEVELOPMENT

What’s in a Wiki? A.L. McMichael
Create Your (FREE) Website Using Github and Jekyll Keith Miyake
Introduction to Web Frameworks Keith Miyake
An Introduction to Web Servers Keith Miyake
Learn Bootstrap Part 3: Customize Bootstrap and Add a Header Keith Miyake
Learn Bootstrap Part 2: Adding Bootstrap to WordPress Keith Miyake
Learn Bootstrap Part 1: Getting Acquainted with Bootstrap Keith Miyake
WordPress 3 Workshop Outline Keith Miyake
WordPress 2 Workshop Outline Keith Miyake
Introduction to Web Scraping for Researchers Michelle McSweeney
WordPress 2: Categories, Menus, and Widgets Michelle McSweeney
Intro to GitHub, Part I Patrick Smyth
Twitter API Outline Patrick Smyth
Bootstrap Workshop Outline Patrick Smyth
HTML CSS Workshop Outline Patrick Smyth
Handout for Establishing an Academic Digital Identity: WordPress 1 Patrick Sweeney
Posted in Digital Fellows, spring17 | Tagged , , , , , , , , | Comments closed

END/LINE: Revised Project Workplan

It begins. Our revised project workplan is available in our GitHub repository: https://github.com/tlewek/encoded-poetry/blob/master/project-workplan.md

Posted in spring17 | Comments closed

ZINE UNION CATALOG: Revised Project Workplan

After the first official out-of-class meeting, the group decided on the best ways to approach the project regarding our objectives, our skillsets, and the time we have at our disposal before a project draft is due on March 22nd. Jenna’s proposal was as detailed and accurate as it can be, but we agreed on making a few changes on the timeline to match it with the course schedule—in any case, these were very minor changes, so it did not affect the development of the cross-repository catalog envisioned in the first place.

Timeline for the First Month of the Project

March 1st – Assign a team management software to facilitate communication within the group; experiment with individual local installation of Collective Access before deciding on administrative server; develop community management tasks, such as creating social network accounts (Twitter, Facebook), obtaining relevant email lists, and setting up the necessary repositories; finish information gathering process on ZUC culture, metadata, and specific terminology.

March 8th – Install Collective Access on the designated server.

March 15th – Work on the data management plan (DMP) for the project and begin to look at design features for the front-end of the platform.

March 22nd – Review milestones for the project and reevaluate the action plan from that moment on. Draft project due.

Roles & Responsibilities

Jenna Freedman – Project Director. Not only takes on certain aspects of community management (social networking and engagement with the zine community) and project management roles, but also provides big-picture-thinking and makes sure to keep the project true to its mission. The project director is the link that holds the team together.

Lauren Kehoe – Lead Metadata Specialist, Community Manager and Documentarian. Takes advantage of her knowledge and experience in library cataloguing standards to help assess the project in terms of working with metadata. The community manager is also in charge of dealing with external and internal communication.

Aleksandr Segal – Lead Developer. Mainly responsible for building a network administrative environment for the prototype. The lead developer will learn how to set up the webserver with a Collective Access instance and how to upload the QZAP CA profile-xZINECOREx in order to modify the existing environment.  

Marti Massana Ferre – Project Manager, Lead Designer. The person who will be in charge of keeping the project on track and ensuring everyone meets the deadlines. The Project Manager will remind the rest of the group of their targeted goals and update the objectives weekly. Once the back-end of the platform is set up, the lead designer will take part on assessing the visual aspects of the catalog and architecture of the site.

Regardless of their role, it is worth noting the willingness to collaborate in different facets of the project from all the members of the group. For example, although there has to be one webserver in particular assigned as the administrator, everyone is looking forward to working on and gaining experience with individually setting up CA.

Mode of Correspondence & Group Meetings

Aside from meeting in person at least once a week—the designated day being Saturday afternoon—we already created Google Docs, Google Calendar, and Google Drive applications to help keep everything up-to-date. However, we do not want to rely solely on the Google office suite, so we are currently looking into the best team management software according to the characteristics of this project and to our schedules. We already discarded Slack and Asana as possible alternatives since they did not seem to address our needs.

Once we decide on which software to use, we will export the information we have gathered up to this point from the Google applications into the new one.

Where the Data Will Live & Where the Site Will Go

Collective Access is the open-source tool that we will use for this online cross-repository platform. More specifically, to build our catalog we will take advantage of xZINECOREx, the metadata standard created for the QZAP (Queer Zine Archive Project) Collective Access profile. xZINECOREx—as stated in this April, 2013 zine from QZAP—is a refined schema of the Dublin Core standard that addresses issues that apply to zines in particular.

On a separate note, one option the team is considering to host the prototype is a Raspberry Pi as the web server.

Needs & Ways to Ask for Help

Even though, as a group, we are aware of the steps we need to take along the way, it is also true that some questions were raised after the first meeting.

Firstly, as we already introduced above, working with Collective Access means designating one server computer with network connectivity that will enable an administrative environment for the catalog of metadata. However, in order to build up this working environment, are we entitled to server space as students at the Graduate Center, by any chance? This is something that we would really appreciate talking about during next class on Wednesday, March 1st—that would allow us to start creating our Collective Access instance as soon as possible.

Secondly, the other issues that arose involved the purpose of the platform down the line: if the catalog would ultimately feed into WorldCat, what the launch would actually look like, and the role of digitization within the interface. We already started to discuss our thoughts on this matter, but we agreed that it would make more sense to address these issues as the project starts to take shape.

Last but not least, the team also started looking into data management plans and the possibility to contact Steven Zweibel from the Graduate Center Library to help us find the best DMP for this project—either before or after the DMP Tool class on March 8th.

Posted in Uncategorized, ZUC | Comments closed

ZUC Personal Reflection – Week 1

I’ve been given the title of “Documentarian Lady” which will mean a few things…

Officially, I am taking on the role of Lead Metadata Specialist (burgeoning professional interest) and a bit of the Community Manager and Documentarian role originally outlined by Jenna in her proposal. However, after our first out-of-class meeting on Saturday, I also volunteered to take on the initial task of evaluating project management software and will be doing a closer look at providing guidance on a data management plan. More about this will be shared on our group blog post, but we will be collectively deciding on Wednesday on what program to use in order to keep us all on track. The immediate contenders are Trello, as recommended by the DiRT Directory and Taiga as found through an OpenSource.com article. I’m also working on a Google Site.

Although Alex has been designated as Lead Developer, we did discuss that each of us would like to gain experience with building the catalog and Alex has already disclosed that his programming experience is very basic (however, more than the rest of us). I find this component of the project to be most daunting, but I am glad to have the support of my fellow group members in this undertaking. We discussed our plan for reaching out to various parties such as course instructor, digital fellows, Jenna’s cohort of contacts, etc. should our technical know-how be limited.

So far, I am impressed by the group’s commitment to and excitement about the project. We already have a plan for meeting most Saturdays during the semester and have worked out some of the deadlines for making progress on the project (of course, these will be tweaked as necessary). We’ve been contributing to a GoogleDoc so far where our meeting notes are currently living. It has been interesting to be part of the early stages of a project when roles need to be designed and expectations set.

In the fall, I had hoped that Jenna would propose a project around her work with Zines and was very happy when that hope was realized. I found all the project proposals to be interesting, but this project has the most professional resonance with me. I think that building this catalog will strengthen my technical skills as a librarian and I will learn about various DH tools and project components for use in future collaborative projects. Jenna’s openness and willingness to take others’ ideas into account is really inspiring and I I feel strongly that our group will be able to make progress with this project and have a working prototype to debut in May.

Posted in Uncategorized, ZUC | Comments closed

Zine Catalog Development – Week 1 Reflection

Considering I have close to zero programming experience, the role of developer is rather daunting. Luckily, the reason I didn’t object to the role is that much of the developing work will be done with pre-assembled packages such as Collective Access (CA).

Immediately after our class, I began researching the initial steps we will have to take to actually build a site composed of both a back and front-end through the CA framework. According to their installation guide, we will need a designated server computer with network connectivity.

This server must have:

There are fairly basic requirements. I have actually tried setting up my own web server on a Raspberry Pi but came to a dead end when faced with the prospect of establishing a network administrative environment (i.e., allowing myself to access the server and its contents remotely as an administrator).

 

Jenna mentioned she has a Raspberry Pi (and I still have my own) which could be a great option as a host for a prototype. Collective Access has plugins for working with various types of media. Since we will not host any media, I am not planning on implementing any plugins but they could be integrated later if needed or if resources allow.

I believe that this initial sever install will (if the ancient gods are gracious and kind) be relatively simple. The difficulty will most likely come about in attempting to modify the existing environment to work around the catalog format we need, which is one that is compliant with the xZINECOREx (ZC) catalog metadata standard. Jenna informed me that ZC is a slightly modified clone of Dublin Core standard (which Collective Access supports in its vanilla state). Despite the native support of the Dublin Core metadata standard, there are differences. Thus, the project will entail having to modify our CA environment to work around our slightly different standard. We will also encounter some hurdles in accepting catalog record sets and metadata that may have been created according to different standards or that were tagged incorrectly. Modifying the catalog environment and converting metadata to meet the criteria of the ZC standard will be two notable challenges of the project. The zine I linked to above (and link here again), which explains the ZC standard, provided a great tool for generating XML metadata code that is compliant with the standard. Very helpful!

I attempted to build a virtual server as a sandbox for the Collective Access installation. Using Oracle’s open-source Virtualbox software, Ubuntu 16.04 Desktop OS, and the current Linux LAMP stack (link is to instruction on installing the LAMP, I created a virtual environment where I would be able to install Collective Access. Following these instructions, the server environment was created successfully. However, I cannot connect to the server through the internet and, because the CA installation is done remotely through a browser, was unable to install CA. I suspect this was due to the fact that the server was a virtual environment which complicated some of the network stuff. I decided to attempt an installation on my iMac.
Following the instructions provided by CA, I downloaded MAMP. After changing the version of PHP to one compatible with PHPMyAdmin (image attached), I was able to continue with the instructions CA provides regarding creating a new database specifically for the catalog. After all the settings files were properly edited, and after a substantial amount of troubleshooting around what  the “root” folder (image attached), I finally made progress past what I was able to achieve on my earlier attempt via the Virtualbox. Specifically, I got CA to notify me that it was unable to connect to my server (image attached). I tried numerous times to change, delete and re-create, and modify settings for my user profiles leading me to the same error messages. ¯\_(ツ)_/¯

 

Posted in Diary, ZUC | Comments closed

Let’s the adventure begins

The title of this post might sound provocative or, maybe, ironic: on the contrary, my intention is totally different. Indeed, I consider the building of the digital project I am involved in (“Encoding as Close Reading”, proposed by Tom) as an amazing adventure, unpredictable but surely unforgettable,

If every digital project is a collaborative kind of work, I am pretty sure me and the other four members of our group (Gregory, Tom, Michael, and Brian) shared the same feelings during our first approach to the work: apprehension, and a little bit of worry. But I am also sure that everybody will do a great job to build our project, and that the final outcome will be really good.

One of the first, and most relevant, decisions to take is about the definition of our roles. When I voted Tom’s project, I proposed myself as the Community manager: I considered this role as the one where I can bring some expertise to the crew. Anyway, Michael too proposed himself for this role, and so we decided to split our responsibilities: he will take care of the publicity of the project and front-end tasks, while my role will be more related to the building of a TEI community of potential users and to follow the development of TEI outreach and expertise. On this side, I need to acquire more expertise about the TEI encoding: for doing so, Tom has been very helpful in sending me and Michael some interesting links about the role of encoding to study literature, and also another – very precious – with the basic instructions to start to encode. Of course, I will need more practice about this, but I think that a good point will be – during our next meeting – to discuss how many different levels of divisions we want to apply as markers to our poems. TEI allows to encode poetry by metrical and rhytmical division, and also following the more classical schemes of quantity (as quartets or couplets). Not all the poems require the same tools: this decision is strictly related to the kind of poems we want for our prototype. Modern or ancient poems? In a classical or in a sperimental layout?

As for the community of potential users, I could take advantage of a project developed at Indiana University, Bloomington, where I got my Master: professor H. W. Storey built a team of humanists, digital humanists and computer scientists to create Petrarchive, a digital edition of Petrarch’s songbook. I was not directly involved in the encoding of Petrarch’s poems for the site, which followed very specific directions; nevertheless, I am still in contact with the people that worked on the project, and I think they could constitute a useful community of people to test our prototype as beta-users.

This is how I would like to accomplish the responsibilities of my role. I will do my best to help the other members of the group to reach our goals and to build a really good project.

So, let’s the adventure begins.

Posted in spring17, Student Post | Comments closed

NYCDH Week Reflections.

 

I attended two events offered through the Grad Center. One was an introduction to physical computing with Arduino Solo and the second was an introduction to GitHub. GitHub work struck me as the more complicated endeavor but that may be because it requires fiddling with network stuff. For example, setting up my own GitHub account and linking a repository to a folder on my laptop? Not too bad. Figuring out how to prompt another user to accept my addition to their repository? Egh. Collaboration is the essential selling point of GitHub – without it keeping track of changes on large projects would be require a lot of needless work. What made GitHub so great was that it was rewarding to learn, not unlike learning a programming language. I also attempted place ASCII art in the proctor’s tutorial folder which begs the question: Can I use GitHub for memes?

Arduino experimenting was definitely more fun in part because it’s so simple and immediate. I was able to begin going off-course from the tutorial almost immediately because all that was required of me to do so was simply moving some cables. The immediacies of experimenting with physical computing offer certain affordances that tinkering with software cannot. I don’t know how easy collaborative work on Arduino projects would be. Perhaps uploading schematics to GitHub for others to see and makes changes to would be a way to achieve that.

Posted in Diary, Student Post | Comments closed

Spectrm – A Proposal

Hey yall.

I want to include my proposal for everyone to read and consider. You can find it on GitHub by clicking here. Alternatively, read below.

 

Thanks!

 

Abstract:

Collaborative projects – whether it’s building a website or designing a proposal – requires a variety of skills and contributions. While some contributions matter more than others, no work should ever be overlooked. Combining a web-based interface with open-source wearable tech, Spectrm is a system that would enable teams working on collaborative projects to make all participation visible.

With Spectrm, you track the time, duration, and difficulty of your work which is then uploaded to the project’s GitHub repository. Once uploaded, your input can be viewed by the entire team who is then able to give it rating. Utilizing a point system, any and all work that you perform can be given a numerical value according to three simple categories: Design, Labor, and Administrative. With Spectrm, you can show your colors in the kaleidoscope of collaboration.

The Spectrm system:

Any work performed, whether culminating in a deliverable or otherwise, is logged by the user using either a wearable tech or mobile app. The information recorded includes the date and time, as well as the duration of the work performed are automatically logged by the device. After prompting the device to cease recording, the user then inputs three ratings for self-review of that recorded session based on a numerical value system.

This system operates on a range from 0 – 255 for three different categories wherein 0 signifies no contribution to a particular category while 255 signifies an extremely high level of contribution to a category. The categories are Design, Labor, and Administration and each category must be rated from 0 to 255 for every session recorded. Some contributions logged may be valuable exclusively to Design while other may be valuable to a mixture of all three categories. For example, if I spend time on a conference call about the project and then proceed to draft a grant proposal, my work would have contributed to all three categories.

After the recorded session is uploaded from the device to the GitHub repository for the project for which this work is relevant, other contributors to this project are then able to rate the contribution against the same numerical metric. Once the project is completed, each member receives a badge reflecting the total work performed by each individual according to the Spectrm rating they received. The badge will be a color determined by the Spectrm rating based on the RGB system for turning three numerical digits each between 0 and 255 into a color. Thus, Design will be visualized as the color red; Labor as the color green; and Administrative as the color blue. The badge will naturally be a visualization of these categories through color and luminosity.

These badges will be attached to each individual on their personal profile of the Spectrm website where users can use the Spectrm rating system to create future teams.

Deliverables:

  1. A design for physical tech or mobile app that can:

    a) Acquire current date and time, operate a timer initiated and stopped by the user, and prompt the user to input three numerical ratings from 0 to 255;

    b) Send a file with this information to an existing repository on GitHub associated with the project to which the user is contributing.

  2. A design for a web-based interface that:

    a) Logs all Spectrm contributions submitted to a project repository;

    b) Allows team members to add their own rating of value on the contributions submitted by their collaborators;

    Online, user-generated polls that can be distributed via short links can be used as a model for how multiple users can input ratings via a web-interface. This model would have to be adjusted to make access only available to members of the project and to update the document after a new rating has been added.

    c) Saves this data back to the GitHub project repository.

  3. A design for a social-networking website (e.g. Spectrm.com) where:

    Numerous professional social network sites exist that perform similar functions which can be used as basic models. One example is http://www.1procrew.com/ which is used in the professional film, photography, and production industries. Each member has their own customizable profile where unique description can be entered along with values attached to pre-determined fields that are pertinent to the field. In the case of 1procrew.com, expertise with particular cameras or lighting equipment is executed with a numerical value between 1 and 5.

    a) Users have personal profiles for the purposes of networking with potential collaborators on future projects; b) Each completed project results in a badge based on the Spectrm rating received for that project;

    c) Users advertise their cumulative Spectrm badges as well as any pertinent skills;

    d) The users’ GitHub accounts are directly linked to their Spectrm profile.

Scale and Feasibility:

For the purposes of this class, only a small portion of the deliverables above can be accomplished. The true purpose of Spectrm is to enable previously overlooked to be included in the way we determine contribution to collaborative projects. For this reason, the wearable tech device and the social networking site are non-essential and can be considered only once the fundamentals of the system are completed and necessary funding is secured. The fundamental elements of Spectrm are:

  1. A way to log work performed, including through manual data entry;
  2. The creation of a readable file that holds three numerical values;
  3. Saving that file with a customizable filename that can inform others as to the nature of the work this file pertains to;

    Additional details about the nature of work performed such as the content, the result, etc. can be included as additional information in the file to make reviewer more informed.

  4. Sending this file to the desired GitHub directory;
  5. Allowing other people to edit that file so that additional ratings are added;

    a) Restricting access to the file to specified individuals (perhaps through private links).

  6. Saving that file to the repository after each successive edit.

These five tasks are essential to the core of making Spectrm work, i.e. giving contributions that are notoriously difficult to substantiate an identifiable structure. GitHub already employs a visual representation of contributions but is limited the kind of work that can be integrated. This system expands on that methodology of making contribution a visual element.

Roles :

  1. Designers (1-2).

    a) Researching all visual aspects of the project including UI, UX, and branding.

    b) Creating layouts for user-interfaces.

    c) Generating copy.

    d) Working with developers to integrate simplicity of use with functionality.

    e) HTML; CSS

  2. Developers (2-4).

    a) Building various environments for data collection, storage, and movement.

    b) Ensuring that Spectrm can integrate into the GitHub system effectively.

    c) JavaScript; SQL

  3. Producers (1-2).

    a) Estimating time and cost; scalability and feasibility.

    b) Coordinating project schedules.

    c) Prioritizing team resources.

    d) Quality Assurance.

Posted in Student Post | Tagged , | Comments closed

Diary (02/19): The versatility of Digital Humanities

During the NYC Digital Week, I attended four different workshops, which offered me – one more time – the opportunity to touch the different potentiality offered by Digital Humanities tools.

The first workshop I attended was “Sampling for the Digital Humanities”, offered on February 7th by Angus Grieve-Smith. Studies and researches into the Humanities can be very time consuming: a solution to the problem can be the use of a labor-saving device such as a sample, which has – of course – to be big enough to be employed as a proof of the hypothesis we are following in examining a huge amount of data. To build a sample we need the material (the data we want to analyze), a numbered catalogue of our data, a random number generator, and one or more input variables that divide the data into different categories. There are three different kinds of samples: systematic (which break up the data in smaller parts, testing a small part to understand the statistical significance and repeating the test if it is not significant), opportunistic (which find empiric evidence), and random (based on establishing a sequential index number for all the data and an initial sample size, and on the analysis of only a part of the total amount of data). The random can be also stratified, when data already present internal divisions and input variables to divide dataser in different strata of sub-data.

On February 8th, I attended my second workshop, “Making a Minimal Digital Edition of a Historical or Literary Text”, with Alex Gil. We discovered how to create minimal digital editions using Ed, a Jekyll theme designed for textual editors based on minimal computing principles. We discovered how to build a digital edition readable and with footnotes, based on plain-text technology, which constitutes also a static Webpage.

The third workshop was held by our GC Digital Fellow Jojo Carlin on February, 15th, and it was an introduction to GitHub. The workshop was really useful, especially for me because I have no experience of this tool. Thanks to her patience and to her detailed explication, at the end of the workshop we were all able to build our first repository.

The fourth and last workshop I attended was “Planning and Prototyping a Digital Humanities Project”, which Joshua Korenblat moved from Februart 9th to 16th because of the snow storm. This workshop helped me to deal with the concept of space, especially with a two-dimensions space where to represent ideas or processes that are (or will take) taking place in a three-dimensional spaces. This is very useful because it forced my mind to find a logical representation of a process by using digital tools, and the last activity was very relevant because he asked us to draw a hypothetical infographic from a huge database constitued by the most famous people from 4,000 BC to modern times.

 

 

 

Posted in Diary, spring17, Student Post | Tagged , , , , | Comments closed
  • Archives

  • Welcome to Digital Praxis 2016-2017

    Encouraging students think about the impact advancements in digital technology have on the future of scholarship from the moment they enter the Graduate Center, the Digital Praxis Seminar is a year-long sequence of two three-credit courses that familiarize students with a variety of digital tools and methods through lectures offered by high-profile scholars and technologists, hands-on workshops, and collaborative projects. Students enrolled in the two-course sequence will complete their first year at the GC having been introduced to a broad range of ways to critically evaluate and incorporate digital technologies in their academic research and teaching. In addition, they will have explored a particular area of digital scholarship and/or pedagogy of interest to them, produced a digital project in collaboration with fellow students, and established a digital portfolio that can be used to display their work. The two connected three-credit courses will be offered during the Fall and Spring semesters as MALS classes for master’s students and Interdisciplinary Studies courses for doctoral students.

    The syllabus for the course can be found at cuny.is/dps17.

  • Categories

Skip to toolbar