Yesterday, I got a chance to visit the Burnaby LAC office as I worked with a couple of the archivists there while at NRCan. Unfortunately, I didn’t get any pictures, but the tour wasn’t the focus of my visit.
The office is made up of about 5 staff members on the archives side and a few more for the records management side of the facility. The warehouse is pretty big, but stores mostly inactive files still in the custody of the originating department, managed by the records side of the office.
Apparently, the big area of interest for researchers and the public are the Indian Affairs documents including residential schools records.
While the building and facilities are much less impressive than the Ottawa ones, it was really nice to see that everyone knew each other and considered the team their “little family”. I must admit that there are always pros and cons to working in any work place, but it seemed like a more inclusive environment.
For one of my management assignments, I decided to do a job analysis of the current job opportunities.
Purpose
Looking at the various aspects of the job postings to look at where and what opportunities are available as well as what is being looked for.
Methodology
Collected all systems related librarian positions which were primarily either systems or web services from September 1 to October 15. I collected 19 job postings and tallied the various aspects including skills and areas of knowledge required and preferred.
Results
The Basics
Jobs were primarily in academic libraries (17 of 19) and a majority were permanent full time (13). The job subareas and titles differ, but were generally broken down in this way:
Systems & Technical Services
2
Systems
8
Web Services
11
User Experience
1
Jobs were also generally in the East.
Canada
United States
West
1
West
4
Central
1
Central
2
East
4
East
7
Finally of the salaries that were listed the average minimum of $49,000.
Education & Work Experience
No surprise that every single posting required: MLIS degree from ALA accredited school or equivalent.
Most required or preferred at least 2 years of experience, and preferred but did not usually required experience within the area of hiring.
Note that the “type” is an indication of whether the experience needs to be in the same type of library (e.g. academic library by posting from academic library).
Duties
Many positions included non-technical related duties. The top two:
Reference – 37% (7)
General/Student Instruction – 26% (5)
Technology Related Skills & Areas of Knowledge
As the majority of the positions were web services related, there was a bit of a bias towards skills that are web related, but generally for systems, I simply found that there were less specific technology requirements and it was also more diverse. The top technology related required skills & areas of knowledge:
HTML/XHTML – 58% (11)
Web Development/Design – 47% (9)
CSS – 42% (8)
Standards & Best Practices – 37% (7)
Emerging Technologies, Trends, & Issues – 37% (7)
Usability/User Experience – 32% (6)
JavaScript – 26% (5)
As I said, the range was wide and included everything from server administration to proxy to analytics.
General Skills & Areas of Knowledge
What might (or might not) surprise people is that the top required skills and areas of knowledge were general in nature and not technology related.
If anything, I think this trend is encouraging for new graduates as it seems that “soft” skills are more important than the technology/technical skills which frankly, many of us just do not have the opportunity to learn in library school, but with some tech savvy would be more than willing and able to learn on the job.
Limitations
There are some obvious limitations to my analysis. For one, some job postings were no longer accessible as they were closed, which meant that they were not included. For my purposes, I also left out all management positions, such as AUL and director positions.
Another issue is that how qualifications were grouped was very subjective on my part, so may not have been consistent. For example, planning and organization was grouped with project management, but results would have been different if the three had been kept separate.
Possible Future Work
It would be interesting to see what the trends are in general rather than only looking at systems positions, but that would be a much larger effort.
Hopefully this information is useful for anyone else in North America interested in systems related jobs.
So I didn’t do a full post for all the sessions, but the live notes that were taken and presumably, video recordings will later be posted on the Access 2011 website.
Data Visualization
Jer Thorp gave a great talk on the data visualization work he’s done and has been working on at the New York Times. I couldn’t really take notes since so much of it was visual, but he blew a lot of minds with his work, so check out his blog.
My Lightning Talk
What really excited me beyond the work itself was the fact that he mentioned he was doing it all through Processing, so I decided to do a lightning talk to introduce everyone to Processing and more importantly Processing.js.
For those who aren’t familiar with it, Processing is an open source programming language primarily used for dynamic and interactive graphing and data visualization. Processing.js is the sister project which brings processing to the web. What’s the greatest part of processing.js is that a developer can start doing the same sort of thing but from the JavaScript side.
Check out the demos to see what kind of things you can possible do. I am particularly interested in the educational applications, such as giving students interactive graphs to see how mathematical functions work (see the Bezier Curves tutorial).
Added value: web accessible, Drupal plug-in, WordPress plug-in, fun games like a remake of Asteroids on the exhibition page.
See Access Live Notes for Lightning Talks and talks about other tools.
Digital Preservation
what does digital preservation mean? preserving more than objects and items
think on scalability
preserve what matters
start with policy and practice, not a platform
library can’t do it alone, partner with IT, Archives, etc.
need to think strategically
no one answer
some good tools
get started
think about what we can do with partnership
Fail Panel
The fail panel was great, because there were a lot of great stories by the panelists and others. Here are some of the lessons learned from the fail stories.
bleeding edge is not always great
good escape clauses to get out of bad situations
make sure company is stable
don’t make thematic websites – not scalable
don’t be working on original records or have a backup
This was actually my first conference, but I think (and I’m clearly not the only one) it’s been really well put together and the food has especially been awesome, many within great socials. There’s been some tech fail, but that’s expected at every place I think.
I have particularly liked this conference because rather than simply having speakers talk, everyone has been highly encouraged to participate in some way (i.e. hackfest + presentations, lightning talks). I never though I’d be speaker at a conference, especially my first, but with the nature of the talks and encouragement of people got me to do a lightning talk. I think that alone speaks loads to the community.
It’s been an awesome experience, I’ve learnt a lot, and met a lot of great people. I really hope to be able to attend the next one.
Access 2012
Sad to see Access 2011 end, but for next year, a site will be set up to see who will host it, and the planning of the conference will be continued code4lib style.
Marty Tarle from Bibliocommons came to talk about a vendor’s perspective on the open source environment. From the chatter going on, not everyone agreed with everything he talked about, but that would almost be expected with a crowd that seems to have many very big open source supporters. Here are the major points that I jotted down.
Typical Library Software Ecosystem
lots of components
some open source software
lots of proprietary software
all needs to work together
Perception of Proprietary Software Vendors
perceived as closed and inflexible
lack of APIs, difficult to integrate with
long development cycles
If this is true for you, then you’re not working with the right vendors. Vendors should be committed to what the users need.
Focus is Often on the Wrong Things
open sourcing – think that any changes can be made, but inefficient and costly without vendor buy-in
standards support – but standards out of date and limited
direct access to data – think can do whatever want with data, but tremendous duplication of algorithms, infrastucture, operations
Focus Should be on Vendor Cooperation
interoperabililty is a two-way street
vendors need to
proactively enable integrations
proactively integrate other solutions into theirs
Vendor Development & Delivery Models
development
agility is critical
scrum and lean are now the norm
long development cycles are unacceptable
delivery
rapid deployment of new functionality
a lot of it is underlying architecture and a lot of testings
being open and flexible
rapid scaling of hardware
industry trend is towards “continuous deployment”: narrowing the gap between conception and production plus building the analytics to see whether it’s working
Vendor Culture
openness = part of company DNA i.e. being invested in client success
integration = core organizational capability
openness = proactive, continuous effort
What to Ask Your Vendors
pace of innovation
how many releases
how many notes
development model
delivery model
API
public
scalable
flexible
ask about attitude towards open source, whether used any, etc.
Best of Both Worlds
Best to use combinations from both worlds e.g. Evergreen + Bibliocommons
Partnership
Vendors and open source communities can work together. What makes a partnership successful?
