Stanford University’s HighWire Press, webhosts to the BMJ and some 1400 other scholarly journals, convened its spring meeting in Palo Alto, California, on 7-8 June 2010 in warm, sunny weather on the stunning university campus. Some 200 US and UK publishing types attended, and the two days were filled with a real buzz from interesting presentations, Q&A sessions, and formal and informal discussions. Topics included website configuration vs customisation, apps vs mobile websites, search engine optimisation, e-books, and the question of what tools doctors and researchers need from publishers. On the Tuesday morning, a number of publishers reported their experiences with all manner of new (external) services. Various topics and presenters were the same as at the Society for Scholarly Publishing’s annual meeting in San Francisco a few days earlier, and the big idea at both meetings was the move away from desktop access to mobile access, and all that that may mean for web content and its various delivery routes.

It’s good to remember – and be reminded – that web publishing seems lodged in eternal infancy, and that we’re all doing our bit to increase the knowledge of how to do this. It does entail a lot of trial and error, and flexibility and patience are essential attributes for those working on the web (see blog from SSP), regardless of whether they’re technical, editorial, marketing, sales, or other experts. Courage is required to possibly go down blind alleys, learning from the experience, and doing an about-turn or going back to the drawing board and taking a different route altogether. It also seems to require a certain amount of “mucking in,” taking on all kinds of tasks (from the sublime to the ridiculous), rather than sticking rigidly to any particular job description. It doesn’t look as though hard and fast rules are going to be in place any time soon, but HighWire and its publishers are making a sterling effort at moving scholarly publishing on the web ahead. I do not recall earlier meetings as quite this gripping – interesting times and exciting developments, when communicating with peers really is key, and this was the perfect opportunity to do so.

For me, the highlight of the meeting was a presentation by Kent Anderson, publisher and CEO of the Journal of Bone and Joint Surgery – and I apologise if I am beginning to sound like the leader of the man’s European fan club. The topic of his talk – “The End of .[dot]strategy” (see also an earlier Scholarly Kitchen blog) – focused on what he calls “the big website build” and asked if overdesigned homepages stuffed with features are really the way forward and whether publishers regarded these as the main driver of their digital value over the next decade.

Kent sketched out how website designs and functionalities have always reflected the state of technology at any given time – from Web 1.0’s scarce bandwidth, slow modem links, rudimentary browsers, and ineffectual search engines (to name a few), characterised by desktop access, to “shovelware monstrosities” that have “mutated to include e-commerce, supplementary data, rapid online publication, and complex search engines.” And while WiFi, 3G, mobile devices and other emerging technologies, and Web 2.0 have brought about the rise of social networking tools and put users in touch with one another (“from output to sharing”), rather than focusing their attention just on sites’ content, many homepages are still “site centric,” with a focus on vendors, sales, advertising, site licenses, marketing, technology, and editors – but, crucially, not on users. But then, much probably depends on what you define as your users – for bmj.com, “users” in the sense of “readers” (medical professionals/scientists/individual subscribers) do indeed bypass much of sites’ navigation in favour of accessing articles directly from search engines. And maybe librarians as “users”(in the sense of parties that make decisions about paying for web access) require a page that has absolutely everything on it?

Kent’s “fantasy” homepage would include blog listings of articles, PDFs, Facebook, Twitter, and email push features. It would be simple to maintain (lots of automations and feeds), migrate, and navigate. So, rather than redesigning your homepage on a grid, with tabs, double navigations bars, Ajax enabled features, and other ways of surfacing as much information and as many content types as humanly possible, would there be merit in going in exactly the opposite direction and modelling your site on the Google search page or a Twitter homepage, or, in Kent’s words, “a simple website that acts more like a hub for all of the other spokes”? I know which solution I’d prefer, but is it really that simple? Answers on a postcard, please.

Birte Twisselmann is a web editor with the BMJ.