Research Map 002: Software Takes Command p39-42

As my research widens itself, the key I established for this mindmap must grow with it. The new colour code is as follows:

  • Grey is neutral
  • Purple denotes facts and events that can be used in my timeline
  • Blue denotes my own ideas and arguments
  • Green denotes other people’s arguments or ideas that fall on my side
  • Orange denotes other people’s arguments or ideas that I’m not sure about/have no opinion on
  • Red denotes other people’s arguments or ideas that I don’t agree with

light = ideas
dark = arguments

Below i’ve mapped out the points that came about as I read pages 39-42. I flagged up this section of the book to read through in an earlier post. Although I set out to read only these 3 pages, my natural course of reading took me a earlier points in the book too; around page 20 where Manovich defined Cultural Software and page 17 where he commented on the increase of public interest in programming.


Manovich begins this section of the book by pointing out that public knowledge of the history, development and pioneers of cultural software is severely lacking. Compared to the history of literature, cinema, architecture and other cultural practices, our knowledge and, more widely our interest in the development and turning points of the development of software does not match up to the impact that it has made to our way of life.

One idea I had that sprung from this is that, possibly, DIY culture could be a remedy to this. As users of media authoring software, our involvement (especially online) in DIY modifications could be the gateway to improving our awareness. Since the development of software is becoming ever more user-influenced, perhaps people will be more in tune with the origin of new techniques and software capabilities as a result.

The only reservation I have about Manovich’s point on this, is that he is referring here to Cultural Software as a whole. Whereas I think this is true for all cultural software, I’d like to focus more specifically on media authoring software, this will enable me to made more pinpoint suggestions and arguments, rather than trying to apply an idea to the whole spectrum of cultural software.

My current stance on this argument is that currently this may be the case, however there is evidence to suggest that the situation may change in the future, not only for media authoring software – where I expect the phenomenon of DIY software modification to bring us around to a more informed position – but also more widely, in all form of cultural software culture. This idea came from reading over p17 where Manovich states, with reference to the article “A Surge in Learning the Language of the Internet” (March 27, 2012), that there has recently been a significant increase in people taking an interest in programming, through night classes and online learning platforms. Its clear that there is a shift in interest taking place, and I believe that a rise in public knowledge of software pioneers will follow, delayed as it may be. Still, this falls in line with the quote Manovich used at the beginning of the section:

Every description of the world substantially lags behind its actual development.

I also had to read back through the book to define cultural software. My definition, which is now in my glossary is as follows:


On p27 I found an interesting point about the ‘habit’ that content-access software has to ‘leak’ into the neighbouring realm of content-creation software. We hardly ever have software that stays in it’s box: ‘access’ becomes ‘access + authoring’. This gave me the idea that maybe this is simply a mirror to our inability to be content with one task/job/function? Maybe this is why ‘authoring’ becomes ‘authoring and modifying’.

I agree with Manovich that the reason for the dip in public interest when it comes to the history and background of software is largely due to what is commodifyable and what is not. Old movies, art, and video games can still be sold as separate entities to their modern counterparts, but the very nature of software -that it builds and improves upon itself – means that it does not generate the same public interest. I believe that is due to to the split between content and technology. People still want old content, but old tech is pretty much useless and counterintuitive to buy.



Ugh, books

Last Wednesday in my meeting with my mentor, I established a plan to prepare myself for next Tuesday, where i’ll be attending a meetup with motion designers and others in my field. I want to be able to ask the appropriate questions to begin my primary disstertation research and hold up an indepth discussion with people about the DIY culture surrounding the motion design industry. In order to do this, I set myself research tasks… and 7 days later and I have done none of them.

I felt it time to revisit and adjust my plan, tackling the most daunting parts first: reading and organising my findings.

During my meeting, my mentor showed me how best to approach Manovich’s Software Takes Command. To get the most out of my book in the shortest time, I needed to skim and scan it, not read the whole thing cover to cover as I was originally planning.

Above are the subjects I wanted to read around and the page numbers they returned from the idex. Since ‘After Effects’ returned the most results, I began there. Visiting each mention of After Effects in the book and summarising what I found in that section, determining whether it was useful to me or not.


Through this process, I developed a system for organising my reading. When I fill a page of summaries, I can read the sections I picked out in green and yellow then continue.

Links will appear here as I make my way through the sections I picked out above:

Page 39-42 [Here]

Page 43 -51 …