Menu
▾
▴
gmod-ajax
|
From: Steve T. <st...@mo...> - 2007-05-31 16:20:36
|
Hi, Has anyone seen this? Basically XML and Javascript that's converted to Flash/DHTML, so may ultimately solve the dreaded browser incompatibility problems. http://www.openlaszlo.org/ There are some very cool demos and I have seen one bioinformatics app so far (http://www.chromhome.org/chromhome/) -- Steve ------------------------------------------------------------------ Medical Sciences Division Weatherall Institute of Molecular Medicine/Sir William Dunn School Oxford University |
|
From: Hilmar L. <hl...@gm...> - 2007-05-31 16:35:43
|
Are they still using XUL? Interesting - there was some hype 3 years ago around the company, but apparently the closed-source business concept didn't work out? -hilmar On May 31, 2007, at 12:20 PM, Steve Taylor wrote: > Hi, > > Has anyone seen this? Basically XML and Javascript that's converted > to Flash/DHTML, so may ultimately solve the dreaded browser > incompatibility problems. > > http://www.openlaszlo.org/ > > There are some very cool demos and I have seen one bioinformatics > app so far (http://www.chromhome.org/chromhome/) > > -- > Steve > ------------------------------------------------------------------ > Medical Sciences Division > Weatherall Institute of Molecular Medicine/Sir William Dunn School > Oxford University > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== |
|
From: Eric J. <e-...@no...> - 2007-05-31 16:52:43
|
I saw a live demo of this at a local meeting. It was very impressive indeed. It looks like the real deal to me and they have a number of production quality apps written with it. They did some simple examples and apart from having to write 'code' in XML it even seemed relatively straightforward (albeit for a simple app). On 5/31/07, Hilmar Lapp <hl...@gm...> wrote: > Are they still using XUL? Interesting - there was some hype 3 years > ago around the company, but apparently the closed-source business > concept didn't work out? > > -hilmar > > On May 31, 2007, at 12:20 PM, Steve Taylor wrote: > > > Hi, > > > > Has anyone seen this? Basically XML and Javascript that's converted > > to Flash/DHTML, so may ultimately solve the dreaded browser > > incompatibility problems. > > > > http://www.openlaszlo.org/ > > > > There are some very cool demos and I have seen one bioinformatics > > app so far (http://www.chromhome.org/chromhome/) > > > > -- > > Steve > > ------------------------------------------------------------------ > > Medical Sciences Division > > Weatherall Institute of Molecular Medicine/Sir William Dunn School > > Oxford University > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Gmod-ajax mailing list > > Gmo...@li... > > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > |
|
From: Michele C. <mc...@br...> - 2007-05-31 17:03:59
|
On May 31, 2007, at 12:20 PM, Steve Taylor wrote: > Hi, > > Has anyone seen this? Basically XML and Javascript that's converted > to Flash/DHTML, so may ultimately solve the dreaded browser > incompatibility problems. > > http://www.openlaszlo.org/ > > There are some very cool demos and I have seen one bioinformatics > app so far (http://www.chromhome.org/chromhome/) Yeah saw this this morning and it does look very cool. The question is - is it a toy or can you do really fancy things with it? All the demos I've seen aren't really doing any heavy lifting. |
|
From: Eric J. <e-...@no...> - 2007-05-31 17:09:05
|
Hi Michele, > The question is - is it a toy or can you do really fancy things with > it? > > All the demos I've seen aren't really doing any heavy lifting. > I saw an email program (similar to outlook) with all the drag and drop/multiple mailbox functionality that looked really great. It was written by the company that currently maintains OpenLaszlo (of course they didn't show the code!) But for me the prospect of what could be done was pretty amazing. They also seemed like they were really trying to get people to use it, so they might be interested in demoing some stuff privately. |
|
From: Seth C. <sjc...@lb...> - 2007-05-31 17:27:17
|
I took a look at this recently and there still seems to be some real compatibility issues, especially if you don't want to use the Flash engine (apparently the DHTML stuff is very weak). It looks like it still depends on whether or not you're in the Flash is evil camp. -Seth On Thu, 2007-05-31 at 17:20 +0100, Steve Taylor wrote: > Hi, > > Has anyone seen this? Basically XML and Javascript that's converted to Flash/DHTML, so may ultimately solve the dreaded browser incompatibility problems. > > http://www.openlaszlo.org/ > > There are some very cool demos and I have seen one bioinformatics app so far (http://www.chromhome.org/chromhome/) > |
|
From: Ian H. <ih...@be...> - 2007-05-31 18:13:18
|
I did look at OpenLaszlo very cursorily a few months back and concluded that we were doing too much custom stuff with the UI to take much advantage of it. Same as with Google Web Toolkit. I don't think that a genome browser breaks down neatly into the standard set of widgets that are used for most Ajax apps. But that is not a very well-informed opinion; perhaps a Google Maps-type widget is lurking out there that's exactly what we need (though I doubt any available toolkit can do the scary things that Mitch is currently trying with tracks built entirely out of DIVs) I. Steve Taylor wrote: > Hi, > > Has anyone seen this? Basically XML and Javascript that's converted to Flash/DHTML, so may ultimately solve the dreaded browser incompatibility problems. > > http://www.openlaszlo.org/ > > There are some very cool demos and I have seen one bioinformatics app so far (http://www.chromhome.org/chromhome/) > |
|
From: Mitch S. <mit...@be...> - 2007-05-31 20:15:13
|
On Thu, 2007-05-31 at 11:13 -0700, Ian Holmes wrote: > perhaps a Google Maps-type widget is lurking out there that's > exactly what we need (though I doubt any available toolkit can do the > scary things that Mitch is currently trying with tracks built entirely > out of DIVs) I've been experimenting with this over the last few weeks, which is part of the reason I've been so quiet lately. This is still in an extremely sketchy state, but there's enough there to get the idea: http://genome.biowiki.org/test/divbrowser/genome2.html The features are exons from D. melanogaster chromosome 3R. There are about 16,000, of which Firefox is able to show a few thousand on my hardware before it starts to bog down. If you zoom out beyond about 3 megabases the zooming gets to be quite slow, but that's above the point where we're currently switching to a feature density histogram for that track, anyway. There's still some low-hanging fruit performance-wise, so I'm optimistic that it'll scale to a full set of tracks, especially if we're smart about interval search and attaching and detaching things from the DOM. And adjusting the threshold where we switch to a density histogram should accommodate hardware differences. The rationale for using divs is: 1. reduces server side processing/storage for image tiles 2. allows for a nice client-side feature creation/editing UI 3. zooming is cool, but it's more than just eye candy--it helps you keep an intuitive sense of where you are 4. client can cache an entire chromosome worth of features (at least for some tracks)--given where firefox and WHAT-WG are going this may enable offline use in the future. 5. more cross-browser than SVG (I've been testing in firefox and IE 6/7 and I'll be trying for Safari as well) Mitch |
|
From: Aanensen, D. <d.a...@im...> - 2007-06-01 14:57:47
|
Hi, =20 have you by any chance seen MIT's Similie project - Timeline widget?=20 =20 http://simile.mit.edu/timeline/ =20 It struck me that this could be utilised in a gmod-ajax type fashion but = with the timescales converted to sequence co-ordinates for displaying = sequence annotation. =20 this is a very quick (and apologetically shoddy) thrown-together = example that I have done for parsing an EMBL file into XML and using the = 'days' in the timeline to display CDS positions based on annotated = sequence start and end points -=20 =20 http://www.mlst.net/chr/chr.html =20 click on the gene to view homolog details from a database (probably best = to ignore the details!).=20 =20 the scale labels need changing and the iframe at the bottom needs = replacing with a DIV and results AJAX'd in but you can see the kind of = thing I mean. =20 The scales can quite easily be changed, various levels added and custom = graphics added (bioperl glyphs for eg) but I don't know how well it = would scale. =20 one of their examples is here - = http://simile.mit.edu/timeline/examples/dinosaurs/dinosaurs2.html=20 =20 all the best David =20 =20 ________________________________ From: gmo...@li... on behalf of Steve Taylor Sent: Fri 01/06/2007 14:11 To: Mitch Skinner Cc: gmo...@li... Subject: Re: [Gmod-ajax] Openlazlo Hi, > >>perhaps a Google Maps-type widget is lurking out there that's >>exactly what we need (though I doubt any available toolkit can do the >>scary things that Mitch is currently trying with tracks built entirely >>out of DIVs) > > > I've been experimenting with this over the last few weeks, which is = part > of the reason I've been so quiet lately. This is still in an = extremely > sketchy state, but there's enough there to get the idea: > http://genome.biowiki.org/test/divbrowser/genome2.html > > The features are exons from D. melanogaster chromosome 3R. There are > about 16,000, of which Firefox is able to show a few thousand on my > hardware before it starts to bog down. If you zoom out beyond about 3 > megabases the zooming gets to be quite slow, but that's above the = point > where we're currently switching to a feature density histogram for = that > track, anyway. > > There's still some low-hanging fruit performance-wise, so I'm = optimistic > that it'll scale to a full set of tracks, especially if we're smart > about interval search and attaching and detaching things from the DOM. > And adjusting the threshold where we switch to a density histogram > should accommodate hardware differences. > > The rationale for using divs is: > 1. reduces server side processing/storage for image tiles > 2. allows for a nice client-side feature creation/editing UI > 3. zooming is cool, but it's more than just eye candy--it helps you = keep > an intuitive sense of where you are > 4. client can cache an entire chromosome worth of features (at least = for > some tracks)--given where firefox and WHAT-WG are going this may = enable > offline use in the future. > 5. more cross-browser than SVG (I've been testing in firefox and IE = 6/7 > and I'll be trying for Safari as well) > Hey that is really cool! Reminds me of the Integrated Genome Browser = zooming functionality. I would be surprised if OpenLazlo could do the hardcore stuff but was = wondering if it would be worth looking into using the components for = other parts of the interface such as popups, menus, search forms, sidebars, annotation editing etc. Cheers, Steve ------------------------------------------------------------------ Medical Sciences Division Weatherall Institute of Molecular Medicine/Sir William Dunn School Oxford University -------------------------------------------------------------------------= This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Gmod-ajax mailing list Gmo...@li... https://lists.sourceforge.net/lists/listinfo/gmod-ajax |
|
From: Mitch S. <mit...@be...> - 2007-06-08 10:39:15
|
Aanensen, David wrote: > have you by any chance seen MIT's Similie project - Timeline widget? Yeah, I've looked at it and read some of their code. Actually, that was one of the things I used to try and justify the div approach. The code is MIT licensed, so we could incorporate it if we wanted to. I like the popups that point to the thing they describe. The reason I thought it would be good to go in a somewhat different direction was because they have a slightly different set of goals and constraints. Scale, like you mentioned, is one thing that I think we're much more interested in. And scale concerns have driven some of the differences in how I'm doing things, like using the browser's built-in scrolling functionality rather than scrolling by changing the position CSS attributes. The zooming thing is another difference. In a genome browser, I think you're really interested in the relationships between things that are vastly different in size. For example, you want to be able to see how a SNP relates to a gene that's tens of thousands of bases, but on a timeline it's less important IMO to see where a single day falls in a span of a few hundred years. So zooming is something that I think we want to spend more effort on. And getting that to work drove some more differences with Timeline. Generally speaking, it's good to set a high bar for rolling your own implementation of something, but on the whole I think that our particular set of needs is fairly unique and deserves some amount of bespoke code. I do want to make use of as much existing work as possible, though, from simile, prototype, scriptaculous, dojo, openlaszlo, gbrowse, catalyst, wherever. Mitch |
|
From: Mitch S. <mit...@be...> - 2007-06-02 22:49:00
|
On Fri, 2007-06-01 at 14:11 +0100, Steve Taylor wrote: > I would be surprised if OpenLazlo could do the hardcore stuff but was > wondering if it would be worth looking into using the components for > other parts of the interface such as popups, menus, search > forms, sidebars, annotation editing etc. You're right, it's not an either-or thing. My vague impression of Openlazlo is that it wants to do a lot of the work for you, so I'm concerned that it'll be hard to fit in something that's outside of what they have in mind. But I haven't really spent time with it. Mitch |
|
From: Mitch S. <mit...@be...> - 2007-06-04 04:44:29
|
On Fri, 2007-06-01 at 10:32 -0400, Michele Clamp wrote: > What's a div? This may be overkill for answering a simple question, but it's a good jumping off point for me to try and justify this approach. A div is a plain-vanilla HTML element; it's just a rectangle that you can position, style (change the background color/image, border properties, etc.), and put stuff in. Since features are often represented in genome browsers by rectangles, I think divs are a pretty good fit for displaying them. Like with Simile::Timeline, there's a single axis (time for them, reference sequence for us) along which we want to represent start/stop information (events for them, features for us). So most of the time a rectangle is enough. So in this context a div is a way of getting a web browser to draw features on its own, rather than having the server draw features into an image and send the image to the web browser. Having the web browser draw things gives us the flexibility to do lots of interesting things on the client side. Zooming with divs is sort of my pet example, but you could also do things like directly edit features (i.e., click and drag to adjust feature boundaries or create new features). I think a lot of people consider SVG the Right Way of having a web browser draw things, and it's true that divs are extremely limited in comparison, but if you're dealing with things that live on a 1-d axis then divs aren't so bad. And I think people generally underestimate what divs can do: http://genome.biowiki.org/test/divbrowser/genome.html My concern with SVG is that it's less consistently implemented in web browsers. IE doesn't have it at all, though it does have its own vector drawing language (VML). Some people are trying to make javascript libraries that hide the differences between SVG and VML, but when I looked they were relatively immature and limited in functionality, and the ones I looked at presented an immediate-mode API ("draw a line from here to here") on top of a retained-mode system ("there's a line from here to here; remember it and draw it") which I think is backwards. Maybe at some point SVG and/or VML will be the way to go; if we decide to go in that direction we don't have to start from scratch. The server side can be exactly the same as with divs, and a lot of the client side should also be the same. I also think a lot of people see divs as being relatively large heavyweight containers of things, rather than graphical elements in their own right, so relatively few people have done things like Simile::Timeline where the position/size of a div is used to convey information. And it's true, divs are fairly heavy, but they're implemented in C++ and the browser writers put a fair amount of effort into making them fast. I think we've recently gotten to the point where cheap, widespread hardware can use divs to do animation in real time. And going forward I think the browser implementors are going to be giving more consideration to this use case. Mitch |
|
From: Mitch S. <mit...@be...> - 2007-06-04 14:13:32
|
On Mon, 2007-06-04 at 08:22 -0500, Eric Just wrote: > I was under the impression that Openlazlo is a programming language > that lets you draw pretty much whatever you want. You can use > predefined widgets, but you can also define your own by drawing and > filling shapes. The program that you write in Openlaszlo is then used > to generate native DHTML or Flash. My beef with canvas-style immediate-mode (procedural) drawing APIs is that while it's easy to draw things with them, it's harder to make those things clickable. I guess you could make each feature its own DrawView, which would make it easy to tell which feature was clicked on, but how well would that scale? Or if you had one big DrawView, you could get the mouse coordinates from the click event handler and do your own hit-testing. But I'd rather not do hit-testing in javascript if it's already been done in C++ for divs. Also, how is DrawView DHTML implemented for IE? I'm getting flash for the DrawView intro. Again, though, I'm speaking mainly from ignorance here, from a cursory skim of the API docs. I'd be interested in seeing a DHTML Laszlo app with a few thousand on-screen interactive elements. Mitch |
|
From: Eric J. <e-...@no...> - 2007-06-04 15:05:53
|
> My beef with canvas-style immediate-mode (procedural) drawing APIs is > that while it's easy to draw things with them, it's harder to make those > things clickable. I guess you could make each feature its own DrawView, > which would make it easy to tell which feature was clicked on, but how > well would that scale? Or if you had one big DrawView, you could get > the mouse coordinates from the click event handler and do your own > hit-testing. But I'd rather not do hit-testing in javascript if it's > already been done in C++ for divs. > > Also, how is DrawView DHTML implemented for IE? I'm getting flash for > the DrawView intro. > > Again, though, I'm speaking mainly from ignorance here, from a cursory > skim of the API docs. I'd be interested in seeing a DHTML Laszlo app > with a few thousand on-screen interactive elements. Hi Mitch, I have definitely reached my limit in how much I know about Openlaszlo. I just wanted to clarify a couple of points about what was possible with it. I saw a demo and was impressed, I don't think it's as limiting as people were originally thinking. I have never used it or programmed with it. I think the performance also would be similar to a home spun DHTML app, because it generates DHTML. That being said, that's all I really know and I think you have a much better handle of your needs in terms of scalability and the appropriateness of using software such as Openlaszlo for a genome browser. Just thought it was worth a gander. I think things on this list look really great and I am looking forward to the new genome browser. Eric > Mitch > > |
|
From: Mitch S. <mit...@be...> - 2007-06-04 14:54:11
|
On Mon, 2007-06-04 at 10:15 +0100, Steve Taylor wrote: > There are an increasing number of biological techniques that are > producing genome wide quantitative data that require graph like > visualisation, such as array intensities and ChIP-on-chip. While > graphs/plots *can* be broken down into rectangles how do think the div > method will cope with the increased amounts of elements required? This is a really good point that Ian and I have been talking about a lot. The consensus is that there's some density threshold above which you'd have to use images. Images fit well with that kind of dense quantitative data because: 1. there's no layout (bumping) 2. they can be very dense 3. As far as I know, there's no need to click on individual data points, the way you'd click on individual features (and therefore no need for an imagemap). One of the nice things about using divs for feature tracks is that a div's visual span is the same as its region of clickability, so there's no need to specify that separately with something like an imagemap. But if there's no clicking then it doesn't matter. Not needing layout (or text labels) for that kind of data makes it easier to render images on demand, since there's no need to worry about distant elements affecting the image tile that you're rendering. Not having any text (or anything aspect-ratio dependent) in the image tile also makes it possible to scale images on the client without making them look odd. We could just horizontally stretch out the 1-base-per-pixel image for higher zoom levels, which (if you were pre-rendering) would save you a lot of disk space and processing time. Or, if you were rendering on demand, some bandwidth and server CPU. Also, I can't think of any reason you'd want to edit that kind of data the way you might want to edit a feature. Point being, feature tracks and measurement-type tracks are pretty different animals IMO, and while divs are a good solution for feature tracks, images are probably the right way to go for dense measurement tracks. So I think we'd want to have both image-based tracks and div-based tracks side-by-side. AFAICT this shouldn't be too hard. That's the consensus as I see it; personally I think it's fine to visualize ChIP/chip data with a bar graph where each bar is (say) 10 pixels wide, as long as it's easy to zoom in to see more detail. Everyone I've talked to seems to think that's crazy, although no-one seems terribly bothered by the fact that at low zoom levels (say, a whole chromosome) even 1-pixel granular plots will still be averaging over a large area for each visible data point. What I'd like to see (regardless of the image/div decision) are plots that show you not only a mean but also a max and a min (or a standard deviation, or something) for each plot point where averaging has been done. Explicitly acknowledge the fact that the visualization is coarse, in other words. Then coarse visualizations become less scary. That's all just my opinion, though. I'm happy to implement whatever image-based stuff people think is important. I may be somewhat biased about the div thing. Mitch |
|
From: Ian H. <ih...@be...> - 2007-06-04 16:44:14
|
yes, i think that's a fair summary of the consensus. i favor a mixture of divs (for feature tracks, especially those uploaded by general users) and images (for WIG tracks, and potentially for reference annotations that have been curated or are otherwise more official/trusted). there are a few reasons why I believe we wouldn't want to drop to 10-pixel resolution for histograms: the main one is that i think you want the browser to be as high-res as possible. citing technological limitations of javascript as a reason to res down by a factor of 10 will not, i think, cut it with most people. the possibility of zooming in does not make up for this. (you can zoom in on a lot of applications, e.g. Photoshop or even web browsers, but that wouldn't really make up for a pixelated image) you want the high-res display for all sorts of reasons. for example you might want to see whether rising/falling edges in the quantitative data line up with start/endpoints of features. you certainly wouldn't want feature co-ords to be rounded to the nearest 10 pixels & so there is also a consistency argument here (e.g. you will be able to pick out introns from a pixel-accurate feature view, but they'll be lost in a nearest-10-pixel histogram view) or, the difference between 10 pixels and 1 pixel might be enough to stop you resolving two peaks that are close together. at 10 pixels they would look like a single peak. when you res down you're shoving everything through a low-pass filter. yes, you are always losing *some* information like this at any zoom level (except the closest), and you *can* always zoom in, but are you going to do that at every position? scroll, zoom in, zoom back out, scroll again? i think this goes against the way that people use browsers. they try to get as much information on the page as possible. this is just an empirical observation (albeit anecdotal): people like big displays that they can then sit back & gaze at. there is already a tension between wanting to display as much genomic context as possible (on the one hand), and being limited by the finite screen resolution (on the other). aside from the dynamic view, there's also the static. people like to save or print out the browser view, for use in presentations or posters or talks. More or less every talk at the recent CSHL Biology of Genomes meeting (for example) had some kind of histogram, and as Lincoln pointed out, they were all high-res. This is one of the big (possibly under-appreciated) uses of the UCSC browser: people like to print the image. I doubt that they'd do that if the WIG tracks were all chunky. I feel that we have to pay attention to the way that people actually use genome browsers, and be careful about saying "oh, you won't need that functionality, you can just do XYZ instead". while that may sometimes be true, i think that the burden of proof is on the side of novelty, where we have less direct experience of how people would take to the paradigm. BTW, I think Edward Tufte (author of the classic "The Visual Display of Quantitative Information", 1983) would probably agree with me on this. From http://www.csiss.org/classics/content/44 "Finally, Tufte was a proponent of high data density. He defined it as the ratio of the number of entries in a data matrix to the area of the data graphic. Of course, such a ratio is often hard to quantify, but his point was clear: don't waste a large graphic on a small amount of information. If there are only a couple data entries, a table within the text makes more sense than creating a histogram with only a handful of bars. One example of a graphic using a high density of data showed the amount of sunny versus clouded periods for each day throughout the year at a given location. Another featured a pollution map that was repeated multiple times to create a form of animation over the course of a day." Of course, Tufte wrote his book on the cusp of computer apps that allow you to zoom in, but I think that this is the whole crux. It's far from obvious to me that people will trade a rich visual display for a worse display with a better zoom dial. Especially when we can give them both the rich display AND the zoom dial. -Ian Mitch Skinner wrote: > On Mon, 2007-06-04 at 10:15 +0100, Steve Taylor wrote: >> There are an increasing number of biological techniques that are >> producing genome wide quantitative data that require graph like >> visualisation, such as array intensities and ChIP-on-chip. While >> graphs/plots *can* be broken down into rectangles how do think the div >> method will cope with the increased amounts of elements required? > > This is a really good point that Ian and I have been talking about a > lot. The consensus is that there's some density threshold above which > you'd have to use images. > > Images fit well with that kind of dense quantitative data because: > 1. there's no layout (bumping) > 2. they can be very dense > 3. As far as I know, there's no need to click on individual data points, > the way you'd click on individual features (and therefore no need for an > imagemap). One of the nice things about using divs for feature tracks > is that a div's visual span is the same as its region of clickability, > so there's no need to specify that separately with something like an > imagemap. But if there's no clicking then it doesn't matter. > > Not needing layout (or text labels) for that kind of data makes it > easier to render images on demand, since there's no need to worry about > distant elements affecting the image tile that you're rendering. > > Not having any text (or anything aspect-ratio dependent) in the image > tile also makes it possible to scale images on the client without making > them look odd. We could just horizontally stretch out the > 1-base-per-pixel image for higher zoom levels, which (if you were > pre-rendering) would save you a lot of disk space and processing time. > Or, if you were rendering on demand, some bandwidth and server CPU. > > Also, I can't think of any reason you'd want to edit that kind of data > the way you might want to edit a feature. > > Point being, feature tracks and measurement-type tracks are pretty > different animals IMO, and while divs are a good solution for feature > tracks, images are probably the right way to go for dense measurement > tracks. So I think we'd want to have both image-based tracks and > div-based tracks side-by-side. AFAICT this shouldn't be too hard. > > > That's the consensus as I see it; personally I think it's fine to > visualize ChIP/chip data with a bar graph where each bar is (say) 10 > pixels wide, as long as it's easy to zoom in to see more detail. > Everyone I've talked to seems to think that's crazy, although no-one > seems terribly bothered by the fact that at low zoom levels (say, a > whole chromosome) even 1-pixel granular plots will still be averaging > over a large area for each visible data point. What I'd like to see > (regardless of the image/div decision) are plots that show you not only > a mean but also a max and a min (or a standard deviation, or something) > for each plot point where averaging has been done. Explicitly > acknowledge the fact that the visualization is coarse, in other words. > Then coarse visualizations become less scary. > > That's all just my opinion, though. I'm happy to implement whatever > image-based stuff people think is important. I may be somewhat biased > about the div thing. > > Mitch > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax |
|
From: Steve T. <st...@mo...> - 2007-06-01 13:11:36
|
Hi, > >>perhaps a Google Maps-type widget is lurking out there that's >>exactly what we need (though I doubt any available toolkit can do the >>scary things that Mitch is currently trying with tracks built entirely >>out of DIVs) > > > I've been experimenting with this over the last few weeks, which is part > of the reason I've been so quiet lately. This is still in an extremely > sketchy state, but there's enough there to get the idea: > http://genome.biowiki.org/test/divbrowser/genome2.html > > The features are exons from D. melanogaster chromosome 3R. There are > about 16,000, of which Firefox is able to show a few thousand on my > hardware before it starts to bog down. If you zoom out beyond about 3 > megabases the zooming gets to be quite slow, but that's above the point > where we're currently switching to a feature density histogram for that > track, anyway. > > There's still some low-hanging fruit performance-wise, so I'm optimistic > that it'll scale to a full set of tracks, especially if we're smart > about interval search and attaching and detaching things from the DOM. > And adjusting the threshold where we switch to a density histogram > should accommodate hardware differences. > > The rationale for using divs is: > 1. reduces server side processing/storage for image tiles > 2. allows for a nice client-side feature creation/editing UI > 3. zooming is cool, but it's more than just eye candy--it helps you keep > an intuitive sense of where you are > 4. client can cache an entire chromosome worth of features (at least for > some tracks)--given where firefox and WHAT-WG are going this may enable > offline use in the future. > 5. more cross-browser than SVG (I've been testing in firefox and IE 6/7 > and I'll be trying for Safari as well) > Hey that is really cool! Reminds me of the Integrated Genome Browser zooming functionality. I would be surprised if OpenLazlo could do the hardcore stuff but was wondering if it would be worth looking into using the components for other parts of the interface such as popups, menus, search forms, sidebars, annotation editing etc. Cheers, Steve ------------------------------------------------------------------ Medical Sciences Division Weatherall Institute of Molecular Medicine/Sir William Dunn School Oxford University |
|
From: Michele C. <mc...@br...> - 2007-06-01 14:32:13
|
All right then I'll bite and show my ignorance. What's a div? Nice demo though - I like the swoopy zooming. On May 31, 2007, at 4:15 PM, Mitch Skinner wrote: > On Thu, 2007-05-31 at 11:13 -0700, Ian Holmes wrote: >> perhaps a Google Maps-type widget is lurking out there that's >> exactly what we need (though I doubt any available toolkit can do the >> scary things that Mitch is currently trying with tracks built >> entirely >> out of DIVs) > > I've been experimenting with this over the last few weeks, which is > part > of the reason I've been so quiet lately. This is still in an > extremely > sketchy state, but there's enough there to get the idea: > http://genome.biowiki.org/test/divbrowser/genome2.html > > The features are exons from D. melanogaster chromosome 3R. There are > about 16,000, of which Firefox is able to show a few thousand on my > hardware before it starts to bog down. If you zoom out beyond about 3 > megabases the zooming gets to be quite slow, but that's above the > point > where we're currently switching to a feature density histogram for > that > track, anyway. > > There's still some low-hanging fruit performance-wise, so I'm > optimistic > that it'll scale to a full set of tracks, especially if we're smart > about interval search and attaching and detaching things from the DOM. > And adjusting the threshold where we switch to a density histogram > should accommodate hardware differences. > > The rationale for using divs is: > 1. reduces server side processing/storage for image tiles > 2. allows for a nice client-side feature creation/editing UI > 3. zooming is cool, but it's more than just eye candy--it helps you > keep > an intuitive sense of where you are > 4. client can cache an entire chromosome worth of features (at > least for > some tracks)--given where firefox and WHAT-WG are going this may > enable > offline use in the future. > 5. more cross-browser than SVG (I've been testing in firefox and IE > 6/7 > and I'll be trying for Safari as well) > > Mitch > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax |
|
From: Aanensen, D. <d.a...@im...> - 2007-06-01 16:19:46
|
Dear Ann Loraine It certainly is, you can focus the window using a call to a = centerTimeline(xxx) function using the href tag in the html - where xxx = is a date (ie the sequence base position) have a look at this - = http://simile.mit.edu/timeline/examples/religions/religions.html (I = can't be responsible for the subject matter!) all the best David -----Original Message----- From: Ann Loraine [mailto:alo...@gm...] Sent: Fri 01/06/2007 16:32 To: Aanensen, David Subject: Re: [Gmod-ajax] Similie =20 This is nice! Is it possible to focus the zooming at a single position or selection, = so that the item you want to examine in detail doesn't scoot off the screen = as you zoom in? Yours, Ann Loraine On 6/1/07, Aanensen, David <d.a...@im...> wrote: > > Hi, > > have you by any chance seen MIT's Similie project - Timeline widget? > > http://simile.mit.edu/timeline/ > > It struck me that this could be utilised in a gmod-ajax type fashion = but > with the timescales converted to sequence co-ordinates for displaying > sequence annotation. > > this is a very quick (and apologetically shoddy) thrown-together = example > that I have done for parsing an EMBL file into XML and using the = 'days' in > the timeline to display CDS positions based on annotated sequence = start and > end points - > > http://www.mlst.net/chr/chr.html > > click on the gene to view homolog details from a database (probably = best > to ignore the details!). > > the scale labels need changing and the iframe at the bottom needs > replacing with a DIV and results AJAX'd in but you can see the kind of > thing I mean. > > The scales can quite easily be changed, various levels added and = custom > graphics added (bioperl glyphs for eg) but I don't know how well it = would > scale. > > one of their examples is here - > http://simile.mit.edu/timeline/examples/dinosaurs/dinosaurs2.html > > all the best > > David > > > > ------------------------------ > *From:* gmo...@li... on behalf of Steve = Taylor > *Sent:* Fri 01/06/2007 14:11 > *To:* Mitch Skinner > *Cc:* gmo...@li... > *Subject:* Re: [Gmod-ajax] Openlazlo > > Hi, > > > > >>perhaps a Google Maps-type widget is lurking out there that's > >>exactly what we need (though I doubt any available toolkit can do = the > >>scary things that Mitch is currently trying with tracks built = entirely > >>out of DIVs) > > > > > > I've been experimenting with this over the last few weeks, which is = part > > of the reason I've been so quiet lately. This is still in an = extremely > > sketchy state, but there's enough there to get the idea: > > http://genome.biowiki.org/test/divbrowser/genome2.html > > > > The features are exons from D. melanogaster chromosome 3R. There = are > > about 16,000, of which Firefox is able to show a few thousand on my > > hardware before it starts to bog down. If you zoom out beyond about = 3 > > megabases the zooming gets to be quite slow, but that's above the = point > > where we're currently switching to a feature density histogram for = that > > track, anyway. > > > > There's still some low-hanging fruit performance-wise, so I'm = optimistic > > that it'll scale to a full set of tracks, especially if we're smart > > about interval search and attaching and detaching things from the = DOM. > > And adjusting the threshold where we switch to a density histogram > > should accommodate hardware differences. > > > > The rationale for using divs is: > > 1. reduces server side processing/storage for image tiles > > 2. allows for a nice client-side feature creation/editing UI > > 3. zooming is cool, but it's more than just eye candy--it helps you = keep > > an intuitive sense of where you are > > 4. client can cache an entire chromosome worth of features (at least = for > > some tracks)--given where firefox and WHAT-WG are going this may = enable > > offline use in the future. > > 5. more cross-browser than SVG (I've been testing in firefox and IE = 6/7 > > and I'll be trying for Safari as well) > > > > Hey that is really cool! Reminds me of the Integrated Genome Browser > zooming functionality. > > I would be surprised if OpenLazlo could do the hardcore stuff but was > wondering if it would be worth looking into using the components for = other > parts of the interface such as popups, menus, search > forms, sidebars, annotation editing etc. > > Cheers, > > Steve > ------------------------------------------------------------------ > Medical Sciences Division > Weatherall Institute of Molecular Medicine/Sir William Dunn School > Oxford University > > = -------------------------------------------------------------------------= > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > > = -------------------------------------------------------------------------= > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > > --=20 Ann Loraine Assistant Professor University of Alabama at Birmingham http://www.transvar.org 205-996-4155 |
|
From: Mitch S. <mi...@ar...> - 2007-06-08 12:20:47
|
-----Original Message----- > > From: Ann Loraine [mailto:alo...@gm...] > Sent: Fri 01/06/2007 16:32 > To: Aanensen, David > Subject: Re: [Gmod-ajax] Similie > > This is nice! > > Is it possible to focus the zooming at a single position or selection, so > that the item you want to examine in detail doesn't scoot off the > screen as > you zoom in? > This isn't implemented, but technically it's not too hard; in fact if you zoom out when you're close to the edge of a chromosome you can see that the fixed point of the zoom isn't at the center. It should be easy to do something similar for zooming in (there's already a "zoomLoc" that usually defaults to 0.5 but gets set differently when zooming out near the edge). It's less a question of technical possibility than one of how the UI should work. I was just looking at PlantIGB. Am I missing something, or is the scrollbar the only way to scroll? I think click-and-drag is a much nicer way to scroll, especially when you're zoomed way in and a small scrollbar movement might take you several screens over. But if you're scrolling by click-and-drag, then IMO it's a little confusing to overload the click to set the hairline as well. Maybe we could have a region in which you click to set the zoom focus point. Or maybe we could have a double-click zoom in around the click position. One of the things I'd very much like to do at some point is get some relatively naive (to our software) users in here to watch them using it. When I was working in a biology lab I found that incredibly helpful for understanding how a UI should work. We've got biology undergrads coming out of our ears here so maybe we could bribe some with free pizza or something. It's useful to discuss UI issues on this list, but IMO user testing is the final arbiter of what does or doesn't work. It certainly is nice to have some IGB/Apollo/GBrowse veterans to talk to, though. Mitch |
|
From: Steve T. <st...@mo...> - 2007-06-04 09:15:55
|
Hi Mitch, > On Fri, 2007-06-01 at 10:32 -0400, Michele Clamp wrote: > >>What's a div? > > > This may be overkill for answering a simple question, but it's a good > jumping off point for me to try and justify this approach. > > A div is a plain-vanilla HTML element; it's just a rectangle that you > can position, style (change the background color/image, border > properties, etc.), and put stuff in. > > Since features are often represented in genome browsers by rectangles, I > think divs are a pretty good fit for displaying them. Like with > Simile::Timeline, there's a single axis (time for them, reference > sequence for us) along which we want to represent start/stop information > (events for them, features for us). So most of the time a rectangle is > enough. There are an increasing number of biological techniques that are producing genome wide quantitative data that require graph like visualisation, such as array intensities and ChIP-on-chip. While graphs/plots *can* be broken down into rectangles how do think the div method will cope with the increased amounts of elements required? Regards, Steve > > So in this context a div is a way of getting a web browser to draw > features on its own, rather than having the server draw features into an > image and send the image to the web browser. Having the web browser > draw things gives us the flexibility to do lots of interesting things on > the client side. Zooming with divs is sort of my pet example, but you > could also do things like directly edit features (i.e., click and drag > to adjust feature boundaries or create new features). > > I think a lot of people consider SVG the Right Way of having a web > browser draw things, and it's true that divs are extremely limited in > comparison, but if you're dealing with things that live on a 1-d axis > then divs aren't so bad. And I think people generally underestimate > what divs can do: > http://genome.biowiki.org/test/divbrowser/genome.html > > My concern with SVG is that it's less consistently implemented in web > browsers. IE doesn't have it at all, though it does have its own vector > drawing language (VML). Some people are trying to make javascript > libraries that hide the differences between SVG and VML, but when I > looked they were relatively immature and limited in functionality, and > the ones I looked at presented an immediate-mode API ("draw a line from > here to here") on top of a retained-mode system ("there's a line from > here to here; remember it and draw it") which I think is backwards. > > Maybe at some point SVG and/or VML will be the way to go; if we decide > to go in that direction we don't have to start from scratch. The server > side can be exactly the same as with divs, and a lot of the client side > should also be the same. > > I also think a lot of people see divs as being relatively large > heavyweight containers of things, rather than graphical elements in > their own right, so relatively few people have done things like > Simile::Timeline where the position/size of a div is used to convey > information. And it's true, divs are fairly heavy, but they're > implemented in C++ and the browser writers put a fair amount of effort > into making them fast. I think we've recently gotten to the point where > cheap, widespread hardware can use divs to do animation in real time. > And going forward I think the browser implementors are going to be > giving more consideration to this use case. > |
|
From: Eric J. <e-...@no...> - 2007-06-04 13:22:17
|
> > You're right, it's not an either-or thing. My vague impression of > Openlazlo is that it wants to do a lot of the work for you, so I'm > concerned that it'll be hard to fit in something that's outside of what > they have in mind. But I haven't really spent time with it. I was under the impression that Openlazlo is a programming language that lets you draw pretty much whatever you want. You can use predefined widgets, but you can also define your own by drawing and filling shapes. The program that you write in Openlaszlo is then used to generate native DHTML or Flash. http://www.openlaszlo.org/lps/docs/guide/drawview-intro.html > Mitch > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X