Topics to be discussed at upcoming meeting of participants

The Layout Voting Page

• Go to the LayoutVotingPage to vote and enter layout-specific comments

Goals of the meeting

• Discuss the merits of Layouts One, Two, Three, Four, and Five
• Arrive at a tentative format to apply to the entire atlas

Comments - Repository of Selected Comments from the Medical Histology Topic Pages

• What a great idea! Pretty gutsy. Put the participants, including me, on notice. How about one more layout? I am continuing to work on Layout 5. Could you take a subheading like the Ureter (there are only 4 images) and use the image plugin with a table to generate thumbnails and then link to each of the four images on the same topic page (no external links except to the image repository). Only this time, have floating text tied to the images. I have an editor ready to work on the urinary chapter. He is from the Johns Hopkins Division of Nephrology. His contribution will further demonstrate the effectiveness of Wiki technology for academic collaboration among geographically distanced institutions. His contribution will begin to evolve the atlas into a Wiki based textbook of medical histology. His entire contribution will be solely to generate content. There needs to be a way to associate an image with a "figure caption" of considerable length. I suspect that this will involve forms. A form showing the image and a text entry field might be the ticket for authoring. Then submitting the form would update the image and floating text in place within the topic. You can see a form in action on the home page that was created when you registered. -- LorenEvey - 23 May 2007
• Speaking of the printable link. Try this "skin" in layer 5. You will notice that performance and readability is greatly enhanced as long as you navigate local links. Yet another argument for one chapter per topic page. One click on a outside link and the browser/server is apt to re-cache with a performance hit. Admittedly, the typical user is not going to appreciate printable viewing. Nevertheless, I am interested in implementing a "performance" skin. -- LorenEvey - 23 May 2007
• Another argument for a chapter per page is to simplify printing. There are tools for generating a pdf document from a topic page. This could be very handy for those who want a hardcopy of the atlas. Further, for those who are annoyed by the left hand column and TWiki links, they can switch to the printable layout. This is advantageous to low resolution monitors. Admittedly, most people will not even notice the printable link at the top right but it is there and I frequently use it. -- LorenEvey - 23 May 2007
• I agree that a child page is the way to do for an index or for information that applies across chapters. For example a glossary would be best in a child topic. Even here, an entire glossary can be in one topic page with targets. -- LorenEvey - 23 May 2007
• Thoughts of how to avoid popups and extensive children/grandchildren guide my "playing" with layout five. To the user, a single topic page can be faster and more intuitive that a plethora of children and grandchildren. The images of a single page can be loaded in the background as a particular image is being studied. The server has time to cache predicted requests. Thoughtfully placed links within a page and "in-place" functions like navigable image galleries make a chapter/page solution tenable. The user would know whether they were at a local link or had linked out. Plus, tabbed browsing can be used and it works perfectly well with local links. At least it does in Firefox. Go to layout five and middle mouse click the TOC links. The result achieves much of the function of a popup but is a safer way to do it. For years, I have tried to show people how handy tabbed browsing is to Pubmed and Google searches. Some users just never get the hang of it. These same users will never be able to deal with a popup hidden behind a window. I get calls about this all of the time. Ultimately, if our headings and subheadings are carefully applied, a global TOC can be easily maintained. -- LorenEvey - 23 May 2007
• Be ginger with popups. They are security problems. Users who have properly dealt with security issues to protect their identity will not view popups, myself included. I will not even use IE except when forced to do so for an update. Popup emulation by shelling out to new browser windows/tabs are a possiblity but cross platform and browser compatibility becomes an issue. Flyovers are dangerous enough. Java script is a security problem but we can not escape it. A primary burden I will inherit in administrating the infrastructure of this site will be assuring security and safe viewing. -- LorenEvey - 23 May 2007
• Plus, as a student, I may not know what terms I want to search for. If there's an index, it's more idiot-proofed (or, awake-for-too-many-hours-proofed, anyway!). -- AshleyLPistorio - 23 May 2007
• I think that an index is a great idea. Despite that a search engine is inherently available on every page, many people just don't use them. An index, although arguably barbaric, is apt to be well received. -- LorenEvey - 23 May 2007
• Nothing is written in stone yet, especially knowing what I think is best. The easiest is to let it be linked on every occasion. People should be getting use to this if they are familiar with wikipedia. They have to recollect what they have already looked at. Besides, if they forget then no harm in clicking the link. The downside is that it colors up the text; thus, decreasing readability. But then, links are the way of the WEB. -- LorenEvey - 23 May 2007
• Just an update on the idea of an index-- I like the idea of creating an index of "keywords" once the whole atlas is constructed. If we wait for that, we can rely on the TagMePlugin? to help us out in its construction (at least, as I understand its inner-workings, anyway).
• The other index I am creating, the one for stain abbreviations and definitions/explanations, is constructed and I just need to integrate it into the main atlas once I start making it. The one question about that is- how often do you want a stain abbrevation tagged? Every time it occurs, the first time it occurs (presuming, perhaps in an ill-advised way, that someone will go from start to finish), only in the tables of ID summaries, etc? -- AshleyLPistorio - 23 May 2007
• Additionally, layout four was tailored toward the image gallery plugin. This plugin has strengths in navigation and placement, but weakness in annotation. The image plugin is much more powerful, but possibly much more difficult to work with. They key property of the image plugin is that you can wrap around text. Ultimately, this atlas may stand on its own as a textbook/atlas for medical histology. To that end, every image has to be annotated and justified for its existence. The image plugin will be best for this, but without extensive use of templates and forms, the development could be horrendous. Even if this atlas is to be solely ancilliary to a textbook, it still needs to stand on its own. In layer four I was working on a way to have guidance for every slide. Notice that the image gallery plugin consistently sets the top margin when viewing a single image. Thus, depending on the users screen resolution you can predict how much space is available below an image of a particular size. My screen is 1200 pixels high. I can view both an image of the current default size for the image gallery plugin and a table of identifications up to about 8 rows without scrolling. Thus, I can navigate an image gallery plugin gallery without scrolling and still be able to see the identifications. Try walking ISZ through a gallery over the phone with his 1084 high monitor and I think you will appreciate the merit of these considerations. ISZ often ignors the scroll bars. He is not alone. I suspect the 1200 pixel high monitors will become mainstream in a year or so. Further, many monitors rotate. The atlas would be maximally effective is viewed by a 1600X1200 monitor in portrait mode. These monitors are becoming affordable. We will have to ultimately reach some kind of compromise on the image sizes according to the plugin we use and according to predictions of future technology. -- LorenEvey - 23 May 2007
• In layout four I was particulary interested in parents, children, and levels of subheadings. I hope that we can arrive at a TOC for the entire atlas that has predictable headings and subheadings across chapters. There is merit to considering having a chapter per topic page. In this case there would be 19 topic pages. Each chapter would have it's own TOC with local links. There would be consistancy across chapters. There would be an Introduction page to the entire atlas and a master TOC. You have probably seen the html help documents on the web. They go on forever and they are one page. I am not convinced that one page per chapter is the way to go but I think that doing it this way might simplify navigation. To a degree, we seem to be a bit chained to the current written atlas. Parts may have to be rearranged and rewritten to maximize the power of the WIKI format. I hope that we do not ultimately create an atlas that gives the impression of an "in house" document adpated to the WEB. -- LorenEvey - 23 May 2007
• It may be advantageous that, once we decide on how to handle the images within a chapter, that we design the TOC for the entire 19 chapters. This should help to keep parents and children in order and to assure a useful navigation bar. -- LorenEvey - 22 May 2007
• I find it redundant and a bit awkward to use the word "The" in each subheading when the title uses it. Then again, the subheadings for the galleries have to be differently named or the TOC will only link the higher level subheadings. This is another topic to be discussed in a meeting of the participants. There may be merit in developing a template to ensure a degree of consistency across topics. -- LorenEvey - 22 May 2007
• It seems that there is a manual TOC on each topic page. The built in navigation bar may be sufficient if the topic pages can be placed with their parent topics. This is another issue for a participant discussion. I find that the manual TOC has merit, but that it is not worth the distraction. -- LorenEvey - 22 May 2007
• Flyovers/links will be made for the stain info (e.g. H&E, PAS, etc). For now we decided that slide numbers are arbitrary (whether they are our slide number like B67, or a new slide number like Slide1), but that to retain our own slide numbers will be helpful for the "cleaning up" process of image-checking. This makes referring back to the same slide much more straightforward to take a new picture, etc.
• As for labels- this may be another add-on for later, once the meat and bones of the atlas is established. It will require replacing the old labeled images with new, unlabeled images and then going in by whatever means we find to create new labels that can be toggled. The only other option is to include an extra slide of the unlabeled version... scrolling through thumbs you will be able to toggle back and forth yourself. I think I have all of the unlabeled files to match. -- AshleyLPistorio - 22 May 2007
• It would be helpful if, rather than bitmapping labels in photoshop, labels could be turned on or off using native TWiki extensions. The only solution I can imagine is that labels on or off would have to be supported by the image plugin. This would require extensive programing. Can you think of another solution? I wonder if somehow the drawing plugin could overlay the image with a toggled transparency? -- LorenEvey - 22 May 2007
• Cryptic information needs to be either dropped from the text or, if meaningful, defined by a flyover/link. Unless I am missing something, the "meaningless" references will give the impression that the atlas does not stand on its own. Outside Universities will be discouraged from visiting and using the site. -- LorenEvey - 22 May 2007
• ISZ asked if miniature thumbnails could be placed within the atlas text. Yes, the ImageGallery plugin is capable of this. -- LorenEvey - 21 May 2007
• ISZ asked whether a registered user could take notes on the content of the Atlas. In a sense yes. Every registered user is given a home directory on the server. Once a user logs in there is a "home" icon at the top left. The user can use their home page to take personal notes. They can also restrict access so that only they (and the TWiki administrators (Ashley and me)) can see their notes. This can be an on-line workspace for documenting their personal studies. I imagine that ANGEL has this capability but I don't know. -- LorenEvey - 21 May 2007
• There may be benefit to having the description field (flyover content) give more information. For example, a statement about what the particular slide shows or demonstrates. -- LorenEvey - 21 May 2007