(This post originally appeared on Letters to a Young Librarian, and was edited by Jessica Olin.)
Your first year as tenure-track faculty is an odd one. You’re not expected to publish right away, but it’s encouraged that you keep your CV active by adding to it in one way or another. Given the amount of time you spend acclimating to a new workplace during your first year (anywhere, not just in academia), you don’t necessarily have the time or the connections to do anything major. Often you’re expected to spend that first year choosing future research projects, and starting to design your research studies and maybe collect some data if you’re lucky. Sometimes, if you’re like me, you were hired to work on a specific project, and will spend much of your time tackling minor practicalities like building a website from scratch and migrating the entire former site’s content to it. Pish posh.
This forces you to be a bit creative with adding lines to your CV. I’ve looked for limited time and energy-commitment obligations, like less formal writing projects and talks at local chapter meetings. One opportunity I stumbled across on one of the CFP blogs I follow was a call for conference proposal reviewers. I’ve acted as a peer reviewer in the past, so it seemed like a good opportunity for some professional service.
About halfway through the 20-or-so proposals assigned to me for review, I realized that this was much more than just a line on my CV. I’ve submitted many conference proposals in the past (a handful of which were actually accepted,) but being on the other side of the submission process gave me some useful insights for the future. (For the record, the conference was not library-focused, and it was a blind review process, so I feel ok about talking about it publicly.)
First, I shouldn’t have to say this, but based on many of the submissions I reviewed it warrants a mention: Follow. The. Instructions. You’ll read this advice a lot in posts about applying for jobs, but it goes for pretty much any official process in the professional world. Sometimes you think can skip steps. Maybe you know someone. Maybe you’re a big name in the field. Maybe you presented last year. Well, I can’t see your name and I wasn’t at last year’s conference, so do us all a favor and complete all the fields in the form. If I don’t need a certain piece of information I’ll skim over it. Better safe than sorry.
Here’s another piece of advice that comes directly from job application best practices: customize, customize, customize. Maybe you’re submitting a similar proposal to several similar conferences. I don’t care. Take the time to tweak your proposal to at least touch upon this specific conference’s mission and theme. I know you have to put out a lot of proposals just to get a few acceptances, but try to make it feel like this conference is one you actually *want* to present at.
GradHacker recently did a post on Killer Conference Proposals, and while all their tips are good ones, I think their final tip is of particular importance: “Explicitly state an audience takeaway.” Of course *you* find your research interesting and relevant (or at least I hope so). But take a step back and think like a marketer. What are you offering presentation/panel attendees? So many proposals I reviewed talked exclusively about their own experience without in any way addressing why that experience should matter to anyone else. Is the technology you used attainably-priced? Are your assessment standards widely accepted? What kind of implementation time/resources did it take? I’ve sat through many presentations where the project discussed was fabulous, but I came away frustrated because the presenters made no effort to tell me how I could replicate all or part of it, or apply the knowledge elsewhere. Give me something I can use, or reserve this talk for a showcase or project update event.
My last piece of advice doesn’t really apply to a blind review, but I’ll mention it anyway. When I’m participating in an event, I make sure to publicize it throughout my own networks. I like to think this gives a person a reputation as someone who will actively work to help draw in attendees, and thus be an asset to future events.
If anyone else has been part of the conference proposal review process, please leave some tips in the comments! What causes you to reject a proposal outright? What puts a presenter on your good side right away?
Showing posts with label best practices. Show all posts
Showing posts with label best practices. Show all posts
Wednesday, December 4, 2013
Zen and the art of the conference proposal
Thursday, September 12, 2013
anatomy of a crash, part deux
So say your site gets hacked, and you try fixing the index and config files, as I mentioned in the last post. And you try checking the server logs to see what files were messed with so you can replace them with backups. And you turn on error-reporting in your CMS to try to see what's going wrong. And you Google some of the malicious code you found in your files. And say none of these fixes work, or yield any useful information. What now?
Well next you'll want to search for common hacks to your specific CMS and version, to see if anyone can walk you through fixing them. Here's a pro-tip though: in the end, most fixes will just tell you to install a fresh version of the software, and if you're in my situation that's not an option, so learn from our fail. Set up your website in such a way that disaster recovery is a relatively easy job, or at LEAST a viable option.
I will admit that much of this advice is based on my experience with Joomla and Wordpress. I have much less experience with Drupal, so some of it may not apply there. If you're a Drupal person, and have advice for keeping your site safe from hackers, please post it in the comments!
Well next you'll want to search for common hacks to your specific CMS and version, to see if anyone can walk you through fixing them. Here's a pro-tip though: in the end, most fixes will just tell you to install a fresh version of the software, and if you're in my situation that's not an option, so learn from our fail. Set up your website in such a way that disaster recovery is a relatively easy job, or at LEAST a viable option.
I will admit that much of this advice is based on my experience with Joomla and Wordpress. I have much less experience with Drupal, so some of it may not apply there. If you're a Drupal person, and have advice for keeping your site safe from hackers, please post it in the comments!
- Keep your site software up to date.
Also your plug-ins. Also your themes. Because chances are, if they're all from reputable sources, the developers will be addressing vulnerabilities as they pop up. The world of hacking is a shifting landscape, and what's secure today is not necessarily secure tomorrow. - Keep your customization modular.
In WordPress, this means using a child theme, rather than making changes to the main theme. When you update a theme, it will override any changes you made to those files. Now you're in a situation where you have stop updating your theme, and are thus breaking RULE NUMBER ONE. You will regret this. - Keep your site root clean.
Actually, not just the site root, but all its sub-directories. Part of the problem with our site is that the root folder is cluttered up with custom includes, images, project folders, etc. If you're not the one who put them there (as in my case, where I'm taking over a site from someone who is no longer here) it's hard to know what folders are part of the CMS's software, and which ones are not.
In general, if you re-install the software, it should just ignore these unrelated files and folders, but if the software contains new files and folders that have the same name as yours, you can accidentally overwrite your files. I'd say either place these files one level up, OR, if you want them to have the site root's url, create one folder in the site root, and put all of it in there. Clearly mark that that folder is NOT part of the CMS's file structure. - Documentation!!!
Srsly. Updating or re-installing your CMS may not be a difficult process, but YOU may not be around when it needs to be done. YOU may be on another continent, or at another job. YOU may have gotten hit on the head or killed those particular brain cells with alcohol. There are so many pieces to a CMS (plugins, templates, images, forms, database(s), etc,) it's supremely helpful to know which of these need to be backed up in like six places before you re-install, so you don't lose the hours and hours of work you put into customizing them. Which leads to... - Keep backups of important files and folders.
Yes, I know you're backing up your entire site on a regular basis, because to not do so would be INSANE, but even so, keep an extra copy of important stuff, JUST. IN. CASE. I have a folder on my desktop with my config file, my entire child theme folder, and my custom plugin folders. WordPress is smart, and names the blank config file something else, so when you update, that default config file doesn't overwrite yours, but still. (Remember to update these backups every time you make a change. I got in that habit anyway, because I keep an entirely local copy of the site to make changes to before making them live, so it's kind of a reflex at this point that when I make a change in one place, I update those files everywhere else.) - Minimize the use of 3rd party modules or vulnerable code.
Wherever possible on our WordPress site, I used CSS/jQuery to create my own custom features (like our tabbed search box) rather than install another plugins. Plugins can increase the vulnerability of your site, so use them with caution (and, not to drill it into your head or anything, but keep them updated!) We've also made the switch to Google forms for all our forms, so we have the benefit of their security features (and so the forms are connected to off-site databases, rather than databases on our servers.) - Create a simple html backup site ready to go at all times.
Honestly, I never even thought of this until the head of Media Services suggested it. Libraries subscribe to many services that are hosted off-site (such as the catalog, research guides, databases, resource managers, and discovery services.) These services are the core of our business, and are still available even when your site is down. Create a simple site that links to whatever services and resources are still available, as well as basic information like hours and contact info. I just downloaded a free CSS template and created a quick and dirty 2 page website that can be put up during downtime (unless the entire server is down. Then I guess you have to put them elsewhere and do a redirect? ACK! SERVER STUFF FRIGHTENS AND CONFUSES ME.)
So ok, there you have it. I am by no means an expert on the topic of hacking, or disaster recovery, or even web development for that matter. This is just an attempt to learn from my own experiences, and to put what I learned out there, just in case it can help someone else in a similar situation. If anyone else has some advice on these matters, please share in the comments!
Labels:
best practices,
CMS,
hacked,
hackers,
hacking,
information technology,
library websites,
site crash,
web design,
websites
Wednesday, May 22, 2013
Spring cleaning your LibGuides
I'm in the process of revamping my library's LibGuides, and I've come across a few small changes you can make to your guides that make a world a difference for design and usability. First of all, as far as headers/banners go, I am NOT a graphic designer, so I kept it simple, with just the school logo, and "Library Research Guides" in our official font. I don't recommend random images and color-fading if you're not really, really good at it. Otherwise it looks like a page for your local pre-K, coded with Microsoft Word.
Second, take advantage of SpringShare's excellent documentation. As a company that markets guide-creation software, they really put their money where their mouth is. Seriously, they've created a guide for pretty much everything. Here are some I found particularly useful:
I've also created a hidden tab (hidden from public view, that is. It's visible to anyone signed in through the admin interface.) I'm using this tab to post instructions, screenshots, and tips for guide creators. I'm also using it as a content repository for boxes I want to be available, but that don't necessarily have a logical home in the template itself (more on this in a minute...)
I've recommended that users link to boxes in the template, rather than copying them, so the template can also act as a content hub, where changes can be made in one place and pushed to all guides linking to the content. This is also why it's a good idea to import your database A-Z list into LibGuides, even if you have one on your library website. If librarians link to links in the database A-Z guide, it will automatically pull the description (which can be hidden or changed if they want) and it will allow you to make changes to database links and names in one place, that, again, will be pushed to all guides that use those links.
I've also noticed that most libraries that use LibGuides just use the default homepage options, which include a list of guides (featured, popular or recent,) a random user profile, email sign-up and/or a tag cloud. But you can choose instead to display a box from elsewhere in the site, by just entering the box id. So, on my hidden template page, I created a box of popular links (I called them "quick links") and put that on the homepage. I also replaced one of the boxes with our "help" box, that contains our various methods of contact. A good example of a nice customized LibGuides homepage is Worcester Poly's site: http://libguides.wpi.edu/
I also like how Rutgers made their homepage a complete list of guides, listed alphabetically on one tab, and by discipline on another: http://libguides.rutgers.edu/home
This is still a work-in-progress, so if anyone has any other helpful hints, please leave them in the comments!
![]() |
old design |
![]() |
new design |
- Changing your banner/adding an image map to your banner
- Customizing LibGuides CSS
- Creating a database A-Z guide with the Serials Solutions importer
- Creating search boxes for your catalog/individual databases
I've also created a hidden tab (hidden from public view, that is. It's visible to anyone signed in through the admin interface.) I'm using this tab to post instructions, screenshots, and tips for guide creators. I'm also using it as a content repository for boxes I want to be available, but that don't necessarily have a logical home in the template itself (more on this in a minute...)
I've recommended that users link to boxes in the template, rather than copying them, so the template can also act as a content hub, where changes can be made in one place and pushed to all guides linking to the content. This is also why it's a good idea to import your database A-Z list into LibGuides, even if you have one on your library website. If librarians link to links in the database A-Z guide, it will automatically pull the description (which can be hidden or changed if they want) and it will allow you to make changes to database links and names in one place, that, again, will be pushed to all guides that use those links.
I've also noticed that most libraries that use LibGuides just use the default homepage options, which include a list of guides (featured, popular or recent,) a random user profile, email sign-up and/or a tag cloud. But you can choose instead to display a box from elsewhere in the site, by just entering the box id. So, on my hidden template page, I created a box of popular links (I called them "quick links") and put that on the homepage. I also replaced one of the boxes with our "help" box, that contains our various methods of contact. A good example of a nice customized LibGuides homepage is Worcester Poly's site: http://libguides.wpi.edu/
I also like how Rutgers made their homepage a complete list of guides, listed alphabetically on one tab, and by discipline on another: http://libguides.rutgers.edu/home
This is still a work-in-progress, so if anyone has any other helpful hints, please leave them in the comments!
Monday, April 15, 2013
MISSION LIBGUIDES: A Guide to Creating Guides that Aren't Awful
I've been tasked by my director to somehow wrangle our LibGuides implementation into shape. Apparently the library subscribed to the software sometime last year, and librarians have slowly been migrating their subject guides from the CUNY-grown SRMS (Subject Management Resource System) to LibGuides. LibGuides offers much more flexibility and back-end usability than SRMS (which was maintained by one person, with all users sending their edits to the e-resources librarian.) Having a system that allows each subject librarian to create and update their own guides makes much more sense, but the ease-of-use and flexibility have a DARK SIDE. Yes. Dark side. In all caps.
So all the librarians, who have varying degrees of technical expertise, are copying and pasting content, willy-nilly, into hastily-created guides in the LibGuides system. Some of them have used the software in the past, and so are comfortable removing unwanted formatting (which often requires you to toggle out of the WYSIWYG and into the html editor) and customizing pages and tabs by adding, removing, or changing the widths of columns. Some of them are understandably daunted by guides that contain giant text and random fonts that they never chose.
I plan on giving a workshop for staff in the coming months, to cover topics such as pasting into a text editor to remove formatting (I've also been installing PureText on people's computers for them. I use it myself, and love it for instant conversion to plain text.) I'll also be going over how to add, remove, and adjust column widths, and when to use special content boxes (such as for multimedia or books from the catalog.)
While putting together this workshop, I've realized that while I can show people how to use the software, I don't really know what to tell them about design. Personally, I can't stand cluttered guides (3 rows of tabs?! Go home LibGuide, you are drunk,) but I can't refer the librarians to any best practice guides outside of the LibGuides system. To this end, I started doing some research to look at best practices (based on assessment/usability testing) for creating subject guides. I'd love to turn this research into an article, but until I see what's already been written on the topic, I can't say if that will happen or not.
I did, however, create a Zotero user group (zotero.org/groups/libguides) for my research, so you can read up on the topic yourself, if you feel so inclined. I'll be adding to it on an ongoing basis, so you can join the group if you want to keep up with what I'm finding. I also opened up comments and discussion, so feel free to share your thoughts. Oh, and if you want me to add you as a contributor to the group, let me know. It might be cool to see what a bunch of us can find, if we all pitch in.
So all the librarians, who have varying degrees of technical expertise, are copying and pasting content, willy-nilly, into hastily-created guides in the LibGuides system. Some of them have used the software in the past, and so are comfortable removing unwanted formatting (which often requires you to toggle out of the WYSIWYG and into the html editor) and customizing pages and tabs by adding, removing, or changing the widths of columns. Some of them are understandably daunted by guides that contain giant text and random fonts that they never chose.
I plan on giving a workshop for staff in the coming months, to cover topics such as pasting into a text editor to remove formatting (I've also been installing PureText on people's computers for them. I use it myself, and love it for instant conversion to plain text.) I'll also be going over how to add, remove, and adjust column widths, and when to use special content boxes (such as for multimedia or books from the catalog.)
While putting together this workshop, I've realized that while I can show people how to use the software, I don't really know what to tell them about design. Personally, I can't stand cluttered guides (3 rows of tabs?! Go home LibGuide, you are drunk,) but I can't refer the librarians to any best practice guides outside of the LibGuides system. To this end, I started doing some research to look at best practices (based on assessment/usability testing) for creating subject guides. I'd love to turn this research into an article, but until I see what's already been written on the topic, I can't say if that will happen or not.
I did, however, create a Zotero user group (zotero.org/groups/libguides) for my research, so you can read up on the topic yourself, if you feel so inclined. I'll be adding to it on an ongoing basis, so you can join the group if you want to keep up with what I'm finding. I also opened up comments and discussion, so feel free to share your thoughts. Oh, and if you want me to add you as a contributor to the group, let me know. It might be cool to see what a bunch of us can find, if we all pitch in.
Labels:
best practices,
LibGuides,
library software,
subject guides,
usability,
UX