Presentation at ESTS 2015

I recently attended the European Society for Textual Scholarship’s 2015 conference held at De Montfort University in Leicester, UK. At this conference, I gave a presentation entitled Beyond Google Search: Editions as Dynamic Sites of Interaction. The focus of the presentation was a discussion around some of the common UI tropes and metaphors we rely upon in Digital Scholarly Editions and an examination of how these elements are applied.  The presentation consisted of a discussion around the subject of interaction design, a break down of the common tropes & metaphors along with a comparison of 14 different scholarly editions and which of the metaphors were utilised, and a brief case study involving the Letters of 1916, a project at Maynooth University with which I have had the pleasure to be involved.

While my plan is turn this presentation into a paper for the ESTS 2015 Variant, I have had some requests for presentation slides, as a few people were interested in the content I have presented. As such, I’ve included a link to a google slides version of the presentation which can be found here.

This presentation just begins to scratch the surface of my research, and I am more than happy to discuss any questions or comments you may have.  Please feel free to utilise the contact form on this blog to get in touch with me.

Happy reading!

Modeling Maynooth Castle Part 3 – The Keep

I started modeling the keep a few days ago and felt I was making good progress.  Unfortunately, I was wrong.  However, I’ve learned a very important lesson:  when doing extrusions on an object, always zoom out to make sure you didn’t accidentally destroy the geometry.  Sadly, this lesson cost me about 3 hours’ worth of work.  Thankfully, I started making regular backups of my saves; otherwise this could have been much worse.

The Process

I started the keep with just a standard cube. I then constructed small towers that went along the tops, and for the crenellations, I did what I have always done—I extruded the polygons of the cube (after converting the cube to an editable polygon). I’ve never had a problem with this. Here is what the top part of the keep (which was the area I was focused on) looked like when I noticed my problem.
Top of Keep
I then zoomed out in order to inspect some aspects of the roof of the keep (for which I was about to create the pitched roof). That’s when I noticed my problem.
Messed Up Keep
As you can see from the photo, quite a bit of the geometry of the keep is distorted. Random sections are extruded or missing. The bottom of the keep was completely distorted. I probably could have fixed it, but I decided the amount of work it would have taken me to fix it most likely would have equaled the amount of time I spent getting to that point since my last back up. So I decided to cut my losses and simply revert to my last backup.

What Went Wrong?

I’m not entirely sure where everything went wrong, to be honest. The only thing I can suspect is that I accidentally selected other polygons while I was selecting the polygons for the roof (either that or I had failed to set the height segments when converting to an editable polygon and thus was extruding the entire height of the keep as opposed to one that was supposed to be closer to 1m3.

Lessons Learned

One lesson I’m taking away from this is to always check my line segments before converting to an editable polygon, and another is to frequently check the entire object when making modifications which affect the geometry. But the most important lesson here is to create FREQUENT backups of my scene. Thankfully, this really saved me this time (as I only lost a few hours’ worth of work), so it’s definitely a lesson I have taken (and am continuing to take) to heart.

Perils of Project Planning

For my contribution to the Woodman Diary, which is the project we are creating for Digital Scholarly Editing, I took on the role of Project Manager.  I thought I would take a few moments to discuss something that is often discussed but overlooked in any software project:  project planning.

What is Project Planning?

Project Planning, as defined by Rouse, is “a discipline for stating how to complete a project within a certain timeframe, usually with defined stages, and with designated resources.” [1] The three components—scope, schedule, and resources—mentioned by Rouse are often referred to as the “Scope Triangle” or “Triple Constraint”. The notion of the “Scope Triangle” dictates that the scope, schedule and resources form three sides of a triangle.  In the “Scope Triangle”, one of these resources is always fixed, and the other two, while flexible, move in proportion to the other.[2] For example, if schedule is fixed—meaning the delivery date of the project cannot be changed—then if additional scope (new features) are added, more resources (also sometimes referred to as budget) must be added to accommodate the increase in scope. The “Scope Triangle” is used to ensure both the stability and the overall quality the project and its deliverables.  After all, one cannot logically assume that a project, which was originally stated to take x number of months with y number of features given a budget of z, can still launch at the same time if the budget is suddenly reduced or if new features are added.

Consider this analogy. You decide to build a new home, and so you hire a company to do the work.  You agree with the company that they will build a 1,000 square foot home in 6 months for €100,000. Three months into the project, you decide 1,000 square feet isn’t big enough, and you wish to add another 500 square feet to the home.  Certainly you would expect it to cost more—and quite possibly take longer—than what was originally agreed to. However, for some reason, this notion often flies out the window with regard to software projects. Thus project managers are often brought in to ensure the “Scope Triangle” is adhered to, and the project remains on track with a high level of quality.

Perils & Pitfalls

Most think of project planning as creating Gantt charts and putting dates on deliverables. And while that is certainly a component, it is far from the only aspect. Below, I’ve listed some of the most common mistakes that can be made in regards to project planning:

  1. Thinking Too Small – project managers need to think big, and I don’t mean in regard to scope.  The biggest mistake that can happen while project planning is not considering all of the possible avenues. What if we lose some of our resources due to illness or vacations? What if the server blows up, and we need to buy a new one? What if some feature we really like isn’t technically feasible? All possible avenues need to be explored during the planning phase.  There is no scenario too far-fetched.
  2. Making Assumptions – often, we make assumptions about the projects we are working on. “The computer centre will set up that server for us.”  “That feature is very easy to implement—I’ve seen it done before.” “That software is easy to customise.” The list of examples is endless. But what if the computer centre is unable to set up the server due to their own time or resource constraints? What is the software isn’t so easy to customise or is restricted due to licensing constraints? What if that feature seen elsewhere took months to build and isn’t distributed and thus must be recreated? All of these items can have a significant impact on a project and cause it to derail.  Therefore, it is important to identify assumptions early on and plan accordingly.  Making assumptions is not necessarily a bad thing, but failing to identify them is a major problem.  If they aren’t identified, then contingency plans cannot be created.
  3. Failing to Identify Risks – every project has risks.  Some are obvious: loss of resources due to illness, scope creep (the subtle addition of new features that, while individually seem small, cumulatively add considerable scope to a project), scheduling constraints, etc.  Every project, however, has risks that are unique to the project itself.  For example, while planning for the Woodman Diary, we identified a risk regarding our software implementation.  At the time, we had yet to choose a software package for the diary, so there was a risk that the package we chose could have an impact on our schedule, as it could potentially be more difficult to implement that we assumed (also, for further emphasis, see above item regarding assumptions). Identifying risks early on allows the team to research mitigation tactics.  In fact, not only should every risk be documented, but a mitigation plan should also be created for each risk in order to identify how likely the risk is, what its impact on the project overall could be, and how the risk will be mitigated. By doing so, the team reduces the potential number of surprises that could arise during implementation.  The fewer surprises, the smoother the implementation.
  4. Forgetting the Goal – every software project has a sense of excitement about it.  The team is creating something new and many participants want to innovate or make something that has that “wow” factor.  Thus, it’s easy to get caught up in the “glitz and glamour” and forget about the goal. Whenever the team is considering adding a new feature or changing an already defined feature, the first question that should be asked is: does this change bring us closer to accomplishing the goal of the project? If the answer is “no”, then the feature should be scrapped.  It doesn’t matter how “neat” the feature might be; if it doesn’t serve the goal of the project, the feature is ultimately a distraction.  Of course, if the team answers that question with “What is the goal?”, then a much bigger problem exists.  Before project planning even begins, a goal must be clearly set out and communicated to—and agreed on by—the team.

Conclusion

Project planning is a vital process of any endeavour, especially when creating or implementing software (and ultimately, every digital scholarly edition is, at its heart, a software project).  It should never be ignored, lest the project fall to chaos and disarray. That said, it is important to remember that it is about more than just marking down due dates next to features and holding the project team to a schedule.  Project planning is also about seeing the big picture and knowing how to respond to various situations that may arise that were unexpected.  Project planning is much like warfare—considering all the various angles and developing strategies for dealing with the enemy. However, in the case of project planning, the enemy is often ourselves and our own failures to look ahead.

References

[1] Rouse, Margaret. “What is project planning?“. Whatis.com. March 2007. Web. 19 April 2015.
[2] Jenkins, Nick. “A Project Management Primer: Basic Principles – Scope Triangle“. ProjectSmart.co.uk. n.d. Web. 19 April 2015.

Further Reading

Haughey, Duncan. “Project Planning: A Step-by-Step Guide”. ProjectSmart.co.uk. n.d. Web.
Kerzner, Harold R. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edition. Hoboken, NJ: Wiley & Sons. 2013. Print.
Project Management Institute. “The Project Management Office: Aligning Strategy and Implementation“. PMI.org. April 2014. Web.
– – -. “The Value of Project Management. PMI.org. 2010. Web.
Sylvie, George, Jan LeBlanc Wicks, C. Ann Hollifield, Stephen Lacy, and Ardyth Broadrick Sohn. Media Management: A Casebook Approach. New York, NY: Taylor & Francis. 2009. Print.