25 June, 2008

The big little things: the colour of genes, default tracks, words.

I was thinking about the web design process for e50 - our new web interface due out in July (definitely will be late July). We're at the stage now where Fiona is going to be asking users their preferences for all the "little things" which make no difference to technical aspects of the web site but make a pretty big difference to the useability. Like, for example, how do we colour our genes? This is a long standing debate where everyone has an opinion and everyone's opinion is right - at least for them. (only 2 colours, and the colours should distinguish manually annotated genes from automatic says one person. No - use the whole spectrum of colours, and make sure we distinguish non-coding RNA genes from pseudogenes from protein coding genes and indicate which ones have orthologs - to mouse. No to rat. No - instead of that use GO functional catagories to colour genes. Or the number of non coding SNPs. Or the gene-wide omega value from the dn/ds measurement)

Sometimes people look at this debate and say that this is a clear area for user defined colours. Which is sort of true for 10 seconds, but - not really. Firstly most users are not going to get around to changing options - partly due to the fact they have better things to do (like design experiments and run them!), partly because this sort of configuration is just a bit too geeky and partly because, to be honest, if they are into configuring things we'd like them first off to work out which tracks that would like displayed (more on this below), and colouring genes should be low on their list. Secondly we want to provide a scheme which feels natural to the most number of people. Hence a rather long series of options to choose from currently being proposed.

The same argument goes for default tracks. (I can't imagine not having SNPs on my display! I can't imagine not having the ESTs switched on!). Everyone has an opinion and everyone is right. Here it is clear we've got to make sensible default decisions (which are also heavily, heavily speed optimised - sadly the new Collections framework wont be ready for SNPs for 50, which is annoying, as really we want SNP density these days in human, but all the other obvious default tracks are pretty well optimised, including some funky scaling stuff to get the continuous basepair comparative genomics measure to come back sensibly when you are zoomed out). But then our main task it to get the user to explore as the "wouldn't it be nice to see xxxx, I wonder if Ensembl has it" with configuration system which is very enticing, but not in the way, and importantly for the non-expert user, not completely overwhelming. In our e50 design means more hierarchy in the options so they can be grouped (itself a bit of pain to handle - we've got alot of tracks), and a nice "light box" effect over the display which reassures you that (a) the thing that you were looking at wont disappear (b) the display will come back quickly. I think we're on the right path here for the configuration, but we still have decide on the default tracks (for me the only obvious one is "Genes").

Finally we've got the mundane business of which words do we use for each of our "pagelet" displays. (our new pagelets are very nice, and in our latest round of testing, >50% of the in-the-lab biologists liked not only the pagelets, but a specific layout of them. less than 10% preferred the current ensembl display). So - we need one or two words to describe "A graphical representation of a phylogenetic tree of a gene with duplication nodes marked". Hmmm. "Gene Tree". Or "Phylogenetic Tree"? (phylogenetic is a bit of a long word, and might get in the way of the menu...). What about "a text based alignment of resequenced individuals with the potential to mark up some features of interest". Is this - "resequencing alignment" or "individual alignment" or "individuals".

If you'd like to take part in this, email survey@ebi.ac.uk (perhaps cc'd to Xose - xose@ebi.ac.uk) to make sure you are on our list. Ideally we'd like you to be wet-lab biologists. We have alot of in-house or near-in-house opinions from bioinformaticians, and in anycase, bioinformaticians are happier to explore configurations etc. Its the researcher who will be visiting us - say - once or twice a month which we think is the main user to optimise for (again, more frequent users we hope will explore configuration to match things perfectly for them).

More on other e50 topics soon - speed, the importance of chocolate in bribing web developers and the end game for e50!

20 June, 2008

Ensembl 50 - technical requirements

Development for the new Ensembl 50 website is progressing well... some of you may have already seen the test sites when you signed up to be part of our testing team...

One of the complaints of the current site (hardware failures aside) is the performance of the webpages - we are addressing this in a number of ways in the Ensembl 50 web code.

  • Tuning the Apache web server configuration:
    Compressing all HTML/Javascript/CSS files using mod_deflate;
    Minimizing the number and size of Javascript/CSS files by stripping unnecessary white space and comments from the files and merging them together;
    Setting headers to improve the browsers caching of content.
  • Aggressively caching content on the server side using a modified version of memcached (this will require Linux users using a 2.6.x kernel as it uses the epoll technology).
  • Increased use of asynchronous HTTP requests (AJAX) to allow more immediate responses for the page while generating other content; and to minimize the content that is sent (can retrieve initially hidden content later)
  • Reducing page size - rather than having single pages containing lots of disparate information having more pages containing smaller amounts of information; this doesn't just help with the page size - but also increases the discoverability of content that we have on the site - which people do not find easily - especially comparative genomics; variational genomics and regulatory information.
For those who will be implementing local copies of Ensembl 50 code - additionally Ensembl 50 code will:
  • Make configuration easier - the pages will configure most of the tracks directly from the contents of the databases;
  • Make code more pluggable:
    ConfigPacker - the SpeciesDefs database parsing; and
    ImageConfig - replacement for UserConfig;
  • Make caching and AJAX implementation easier.
There are a number of changes to the code - so if you have written your own components or drawing code tracks there will be work to be done but in most cases these modifications are easy to implement (e.g. moving code between modules).

Finally, here are some additional system recommendations:
  • Perl 5.8.8 or newer;
  • MySQL 5.0 server;
  • 64 bit architecture;
  • large memory machine;
  • you can compile our modified "memcached" code (e.g. for Linux you will need a 2.6.x kernel) to get significant speed up;

19 June, 2008

Technical Difficulties

For the past two days, Ensembl has been slow or has not returned the page (instead offering an 'Ensembl is down' yellow screen).

Be assured we are working on the problem. It is a hardware issue, but should be resolved soon.

From all of us in the Ensembl team, thanks for your patience!

12 June, 2008

Ensembl needs you!

As you know, we are working on a new website design for the Ensembl 50 release. We are currently seeking 'beta testers' who would be happy to take part in a survey and help us shape the look and feel of the new website.

If you could spare some time we would be very grateful if you could send an eMail to survey@ebi.ac.uk so we can add you to our list of testers.

We are looking forward to hearing from you.
The Ensembl Team

04 June, 2008

Upcoming Workshops - Summer

Hello all,

There are a few Ensembl training events taking place this summer:

(2-day) Browser workshop in the Dept. of Genetics, University of Cambridge, UK (5-6 June)

Module in a Wellcome Trust Mini-Open Door Workshop (ODW) for MalariaGEN in Hinxton, UK (20 June)

Module in a Mini-ODW at the ICG in Berlin (12 July)

Programmers' group at the ISMB meeting in Toronto, Canada (19-23 July)

As ever, email us with any questions (or comments) at helpdesk@ensembl.org

Best Wishes,

03 June, 2008

Ensembl 11 - UCSC 8

The past days I was in Barcelona at the European Human Genetics Conference 2008. After giving my presentation on Ensembl in one of the 'Educational sessions' and listening to numerous talks about GWAS (genome-wide association studies), I had a look at the posters. Under the impression that the UCSC Genome Browser is the preferred browser amongst (human) geneticists and with Ewan's experience at the recent 'Biology of Genomes' meeting fresh in my mind, I decided to have a closer look at the posters in the Cytogenetics section. Out of 189 posters, I could positively identify 11 with Ensembl screenshots (mostly CytoView and ContigView, but also two times KaryoView), 8 with UCSC Genome Browser screenshots and none with NCBI Map Viewer screenshots. OK, I admit that I can recognise almost any pixel copied from our site and may have missed one or two UCSC screenshots, but all in all I thought this was a very encouraging result! Of course we should keep in mind that this was a European conference, mainly attended by European scientists .... I guess I have a bit more screenshot counting to do at the International Congress of Genetics 2008 in Berlin. So, let's say Ensembl 11 - UCSC 8 is the score at half time .... next month I'll report back with the final result!