Back in 2005 whilst working for SOLAS, an international research programme, I was struck by the inefficiency of the methods by which scientific websites, especially project websites were built and maintained. They looked awful (most still do) were built from scratch using dreamweaver, or worse still front page (honestly, in 2005 this was still pretty common in science) and updated via ftp (remember that?). Each project duplicated information (bio, publication list, research interests) about all of its members that could be found on other project websites, their institutional webpage and their personal one. In practice, most of this information was out of date and the html_edit-ftp process was such a “barrier to update” that most project websites were hideously static and barely worth visiting. Frankly pretty pointless.
It was time to try to bring scientific websites into the database-driven web world! I tried to get a CMS-driven, community updated website built for SOLAS, but failed (due to a lack of funding and engagement from project members). Not put off, I decided to try to build the “universal solution” to this problem that would work for individuals and multiple projects alike.
At the dawn of the Facebook age, the idea behind researchpages would have been best described as “MySpace for research” and such it was probably doomed from the start! However, to my knowledge it was the first research-specific community-based site on the web. It was a place for individuals and projects to manage their forward-facing web presence, with some collaborative intra-group tools thrown in for good measure. Developed over the course of 2006 it was only a prototype, which I had hoped to find funding for to build the real deal (which would undoubtedly have been more ‘social’ and more a “Facebook for research”). After a couple of near-misses with substantial funding (enough to have allowed me to quit my day job and worked full time on the site) other (research) projects took priority and rp.net was put on the back burner. It ticked over, mostly problem free for next 5 years, with a bunch of active users (maybe 100) and 5 times as many non-active ones. It was a multi-featured application with multi-column cms, user model, group model, auth model, publications model, wiki, blog, resource/file share, messaging and more! As my first (and to date only) database-driven web project that’s quite an achievement; I’m pretty pleased it survived, and provided a useful service to some people. Nice to know I could have been a proper web developer had I chosen that path. It may yet happen. The science funding runs out pretty soon!
The things I think are still really good about researchpages:
- Simple CMS allows people and projects to maintain a media-rich web presence managed through a browser – no need to learn to build websites! Even the most luddite of users got to grips with the textile markup very quickly.
- Publications are shared between users – i.e. the authors of publications were interlinked. E.g. http://researchpages.net/publications/780/ (I wish Mendeley did that!)
- An individual’s page can be rendered in isolation e.g. http://researchpages.net/people/tim-lenton/ or under a group of which they are a member e.g. http://researchpages.net/esmg/people/tim-lenton/ and http://researchpages.net/QQ/people/tim-lenton/– thus only a single page needs to be maintained with an individual’s details.
However, as it never got past the protoype stage and the internet has moved on and left it firmly on the wrong side of the social media revolution, I think it’s days are numbered. Maybe it was before its time…
Personally I have a blog, an online lab notebook and a twitter account now, and not much need of a personal website in the 2010s. If I were running a research programme I’d probably take the blog-and-twitter approach for that too, although that was a subject of discussion at the Digital Researcher earlier in the week and opinions were split on the value of a website as well as more dynamic content streams.
I’ve learned some important lessons from researchpages which might be useful:
1) keep it simple to start with – don’t have too many features. It confuses users and leaves a trail of mess that needs fixing when you discover bugs.
2) Marketing is all. Without marketing you don’t get the groundswell of users which moves you to the next level. These days that’s a lot easier, by harnessing the power of facebook and twitter – a remarkable number of academics are engaged with these now.
3) Keep developing – researchpages began a slow and painful death when I stopped developing it in 2007. It’s out of date. I’m so unfamiliar with the code now that fixing the problems raised by having to move servers after it got hacked is nigh-on impossible.
4) I thought that to maintain ‘authority’ and be attractive to academics, researchpages needed to have a controlled signup process. Either you ‘applied’ with evidence of your research, or you were signed up as part of a group signup by a group editor. This was silly. Open membership is the only way a) to grow a sufficient userbase to survive and b) to be inclusive. Academics are normal people too! Plus, I just made work for myself, ‘vetting’ people. It wasn’t very stringent – nobody who applied got turned down.
I regret not taking the leap and getting properly into researchpages 5 years ago. At the time it didn’t seem certain to me that the internet revolution would greatly affect academia, partly as I was faced with a great deal of cynicism and negativity from academics themselves when I talked to them about researchages and the ideas behind it. They are a conservative bunch and new concepts don’t progress easily through that sphere. Now it’s plain to see that in a decade or less academia (not just communication of results, but the whole academic process) will be almost unrecognisable as a result of the social media revolution. I hope to be part of that revolution, but researchpages isn’t the vehicle.
However, if anyone would like to take it on, I’m happy to let it go. Maybe Academia.edu or Mendeley would like to buy it 🙂