RSS

Archivi tag: digital edition

EVT version 1.1.1 and version 2.0 alpha released!

Hello everybody,
we are back at you with what may be called a “double feature” release: two new versions of EVT at the same time! Here are the details.

EVT 1.1.1

This version is a follow-up to v. 1.1, which was released for the DH2016 conference, and adds support for yet another specific list (<listOrg>) besides a little refining. The 1.1 and following version was supposed to be a bug fix release, but we actually managed to include new features in it: EVT 1 is going to stay with us for a long time, which means that we definitely want to support it not only with bug fixes, but also with improvements when possible. Do not expect radical changes or brand new features in this version, however.

Here are the most important changes, please read the first item carefully:

  • changed the starting point of the transformation which is now based on <text> (also when using a <group> element): this is the most important difference compared to EVT 1.0, in fact note that the old method based on <div> does not work anymore, so please make sure to read the EVT 1.1.1 manual on this point;
  • added support for image formats other than JPEG;
  • added German language support thanks to Christian Schuster from Transylvania Digital Humanities Centre (DigiHUBB: http://centre.ubbcluj.ro/digihubb/) who actually translated the English localization file;
  • added a template to rend italicized <title>s in <note>s;
  • added files for custom XSLT templates (evt_builder-custom-templates.xsl) and CSS rules (evt_builder-custom-styles.css), check section 3 of the manual;
  • added a distinction between critical <note>s and comment <note>s;
  • renamed evt_builder-miscellaneous.xsl into evt_builder-general.xsl;
  • added initial support for original content encoded into a <front>;
  • added support for <listOrg>;
  • many bug fixes!

Download it from the usual place and please report to us any problem that it may present. Your feedback is very much appreciated, as usual.

EVT 2.0 alpha

As the “alpha” tag suggests, this is not even a beta version of the new EVT 2 version. Actually it is very stable and does what it was created to do (support for critical editions in TEI XML format) quite well, but still has to be refined and, most of all, it lacks many important features available in EVT 1, the most critical one being support for digitized manuscript images.

EVT2 - Testimone frammentario

This is a very important release, however, because it is the first one based on the Angular.js framework and on the MVC design pattern, chosen because it allows to separate the logics of data presentation from the core of their processing. We needed more flexibility and modularity in order to make the development of new features easier and faster, and this has led to a completely new infrastructure: the XSLT stylesheets have been abandoned in favor of a set of JavaScript parsers specifically written to retrieve edition content directly from the XML file. Edition data is then saved in a JSON structure, organized in such a way that it can be easily and rapidly accessed when needed. The final styling of documents is entrusted to CSS style­sheets and is easily customizable.

EVT2 - Filtri

EVT2 - Heat map

Note that the current Javascript parser can only process TEI XML documents, but it is possible to add new parsers for different formats so that they are converted to the intermediate JSON structure, e.g. it is possible to add a custom XML (non­-TEI) parser, a LaTeX parser, etc.

These are the main features available in EVT 2.0 alpha:

  • Critical Edition support: rich and expandable critical apparatus, variant heat map, witnesses collation and variant filtering are some of the main features developed for the critical edition.
  • Bookmark: direct reference to the current view of the web application, considering view mode, current document, page and edition level, eventual collated witnesses and selected apparatus entry.
  • High level of customization: the editor can customize both the user interface layout and the appearance of the graphical components.

EVT2 - Varianti e note critiche

You can go straight to the online test site, but if you want to experiment with it you only have to download the archive from SourceForge and unpack it on your hard drive, after that you click on the index.html file and you are ready to go. If you want to try one of your documents you can do this by simply copying your file in the data folder and then editing the config.json file in the config folder: make sure that the dataUrl variable points to your file, e.g.

"dataUrl"          : "data/my_critical_edition.xml",

This version is the focus of all new development, so please let us know what you think of it writing at the usual contact email. Your feedback is even more appreciated for EVT 2 because this is the first public version and we definitely need to know if the path we have chosen is appropriate.

Many thanks to Marjorie Burghart for the TEI Critical Apparatus Toolbox which allowed us to perform a preliminary test of the TEI Parallel Segmentation method. A modified version of its sample file is the default pseudo-edition text showed in EVT 2.0 alpha.

 

Annunci
 
Lascia un commento

Pubblicato da su luglio 28, 2016 in articles, evt, release

 

Tag: , , , ,

SDE design: The agony and the ecstasy I

During all phases of EVT development the team members have had quite a number of lively discussions about the many topics and problems that such a (relatively) complex project entails: which programming and markup languages to use, basic features to implement in the beta version, the license to adopt when releasing EVT as open source software, the roadmap leading to its first release and subsequent ones, and more. Even considering roadmap-related issues, strictly linked to the financial and human resources available (hint: never enough of both!), the most heated debates revolve about one fundamental issue: which User Interface design for Scholarly Digital Editions should be implemented in EVT. This is easily explained if you think that we share basic ideas about most, if not all, of the technical aspects of software development, and that in any case I can only listen and then give green light on most of those issues, since Chiara, Julia and Raffaele have a competence in strictly technical aspects far exceeding mine; furthermore, roadmap-related issues usually fall in a sort of “external agents” category, be they impending university exams, a deadline for external projects or papers to be delivered, or quite simply a lack of adequate funding for all the nice things we have in mind.

UI (and UX: User Experience) design, on the other hand, is both an aspect of development we all believe to be fundamental for the success of EVT, and an area where every team member has her/his own specific sensitivity/orientation, therefore each of us has her/his own vision with regard how to make EVT “right“. A UI/UX done “right” makes a difference between a research tool that can prove useful to get stuff done, and a way to enjoy exploring and reading a digital edition besides that. Everyone in the team aims at this second goal besides the first one, and everyone has his/her own ideas about how to reach it. UI/UX development for EVT, therefore, is more a bumpy country road, where sometimes you get to regret how slowly you have to walk, than a speedy motorway leading you to the final, commonly shared destination. Also, there are lots of detours, dead-end streets and, of course, suffering and whining because of all the bumps 😉

design-ux

“Getting the UI/UX right” for a software such as EVT is of primary importance for a number of reasons:

  • first of all, what is visible and actionable on the screen is “the edition” for our perspective users: at a markup level the edition is already there, but of course it is “invisible” for the intended public since without a tool such as EVT it wouldn’t be possible to access it, browse it, use it for research purposes or to simply enjoy viewing the manuscript images, reading the texts, and more; “getting the UI/UX right” means “getting the edition right” for all EVT users, and thence it is as important as “getting the edition right” at the markup and editorial level; note that, conversely, the marked up text is invisible to users once the edition has been published with EVT;
  • as noted by several researchers (see for instance Porter 2013 and my own 2011 article), a digital edition is still at disadvantage when compared with traditional printed editions because 1. digital editions are in small or big ways all different 2. you have to learn how to use them, both because of 1 and because they often include tools, such as text search/analysis tools, that are simply not available for printed editions (and, again, are all different in some way while sharing some common UI features); “getting the UI/UX right” also means lowering the learning curve as much as possible, with the ideal goal of making the digital edition as intuitive to use as a printed one;
  • last but not least, on the strictly technical level some aspects of the UI/UX are firmly connected with the internal workings of the software: a convoluted navigation system, for instance, would probably cause unnecessary stress on the software layer devoted to that specific purpose; vice versa, an elegant internal architecture would make it easier to devise an effective navigation method.

The first two points should be clear to everybody involved in the critical digital editing field, both creators and users of electronic editions. Indeed, we have received a good feedback about EVT by users of the Digital Vercelli Book beta, and generally appreciative remarks for its simple and elegant UI. Things are going to get more complicated soon (see below), but it never fails to surprise me how people may not be able to describe exactly what they what, but invariably recognize it when they’re presented with it. This is the general feeling with EVT and the VBD beta, even considering all its limitations, and it was a good one.

UI-like-a-joke

There’s another aspect to feedback, however, and it’s a darker, more troubling one: often the same people who appreciate a well done digital edition, and who are interested in using such resources on the Web, are not interested in taking part, if not in the actual design of such resources, in theoretical discourse about how to improve general usability and effectiveness of Scholarly Digital Editions. There is a general feeling that somehow, somewhere, somebody will come up with exactly the kind of resources that they need; not only that, but also the deeply ingrained conviction that an editor should do just that, prepare critical editions of his/her texts, and avoid at all costs getting involved with how these texts may be displayed and used in a digital edition: after all, this is why we have IT departments and technical personnel, right? not real “textual criticism” in action, is it? I will not surprise anyone by writing that I couldn’t disagree more with this line of thinking: it really is hard for me to imagine how an ICT professional, however excellent in his area of expertise, could design (not implement!) the perfect digital edition tool. Think of the “different layers …” of a critical edition, or even just the complexity of a full critical apparatus: who, if not a textual criticism scholar, is going to “get it right” when it comes to how and where the information is organized and showed to the user? Explaining to a programmer what we have done so far with printed editions, the rationale for critical apparatus etc. is not enough, since it’s the reason why so many first-generation digital editions resemble printed editions so closely, with a fixed layout similar to how the space is used on a printed page for the edition text, the critical apparatus, commentary notes etc.

For real innovation to happen in the SDE area with regard to their UI/UX component we all need to get our hands “dirty” with User Interface design: which doesn’t mean that anyone researching or studying textual criticism has to go out and buy the latest publications in HCI studies, of course, just sending detailed feedback to those creating digital editions and online resources would be a great start and a very appreciated help.

Those actually working on UI design for digital editions, on the other hand, need not only to listen to their own current and prospective users: they also need to put in place an effective way to share, discuss, accept and test UI design proposals. This is not a simple task in any research team, a fact of life that we discovered early during EVT development. The next post will be devoted to the work flow we are currently using and improving (or trying to) to design the next EVT version.

References

Porter, Dorothy C., ‘Medievalists and the Scholarly Digital Edition’, Scholarly Editing: The Annual of the Association for Documentary Editing, Volume 34 (2013) <http://www.scholarlyediting.org/2013/essays/essay.porter.html > [accessed 20 April 2015].

Rosselli Del Turco, Roberto, ‘After the editing is done: designing a Graphic User Interface for Digital Editions’, Digital Medievalist Journal, 7 (2011). <http://www.digitalmedievalist.org/journal/7/rosselliDelTurco/ > [accessed 20 April 2015].

 
Lascia un commento

Pubblicato da su aprile 20, 2015 in articles, evt, UI/UX

 

Tag: , , ,