Off the Top: Information Application Development Entries
Showing posts: 151-165 of 189 total posts
One thing that I have had the benefit of viewing and discussing while at SXSWi is Flash. Folks from Macromedia have shown their soon to be released version of Flash. Flash MX (as it is named) has some very good new features, in its providing common Web development objects to help developers create scroll bars and the like very easily. The application seems to provide object or extensions to Flash that streamline the process to building something usable and consistent in Flash.
The best new feature of Flash is content can now be made accessible for those with sight disabilities. This is greatly helpful as Flash is largely a visual information development and presentation tool. The information is now usable by site readers that read information aloud stored in Flash. This has been a large hinderance for many folks who would like to adopt Flash into their development tool belt, but had restrictions that limited the use of Flash because it locked out a segment of the users who had visual disabilities.
There is one large element in Flash that is completely disappointing still. The information is not accessible for reuse. All Flash can provide is visual information presentation, which restricts a user's ability to copy and paste or to have the information machine readable. The information is locked in an unusable format for these purposes. What does this affect? If a hotel provides their phone number and address in their Flash presentation the user can not copy and paste the information out into their PIM (Outlook, Access, Palm desktop, etc.), to an e-mail, or text message that the user could read from their PDA or cell phone (given messaging capabilities). The user would also be restricted from grabbing the information to put together a matrix from which to make decisions or to supply to others to make their comparisons. The locking of information in Flash requires the user to retype the information provided, which introduces the ability for errors in the information that was carefully crafted.
Not only do human users have the inability to re-purpose the information, which is a great benefit to those providing the information, but machines are precluded from accessing the information. If the same hotel wants to be included in their city's chamber of commerce listing on the CCoC Web site the hotel information can not be easily extracted by the CCoC as it could be from HTML (using an id tag) or XML. The information is locked again in an unusable and un-reusable format. The creators of the content lose, and could possibly lose big by not having information that is easily reused. This becomes increasingly important with the growing use of Web Services that rely on machine readable or machine accessible information.
Why the hotel scenario? Macromedia used the hotel demonstration to highlight some of their great new features. As I watched the presentation I kept wondering if the information was still unusable for purposes other than reading or having the information read to the user. It was later confirmed the information was still un-reusable, but Macromedia is also aware of this strong down side to the information presentation and is working hard at fixing the issues.
Yesterday was all about getting the synapses to fire in the right order at SXSWi. I was running on sever sleep deprivation from phones and alarm clocks ringing when I had not finished my needed sleep cycle. None-the-less I had a great time. I greatly enjoyed Steve Champeon's peer panel on Non-Traditional Web Design, as it focussed on the fine art of tagging content, understanding the uses of information, and the true separation of content, presentation, and application controlling the information. The Web Demo panel I was on seemed to go rather well as there were a broad spectrum of sites reviewed and the information from the panel to the developers was of great use (I hope) as I think we all learned something.
The evening provided good entertainment, a wonderful gattering at the EFF party. Once again many folks adjourned to the Omni Hotel lobby for the after-hours social gathering. I spent much of the time just listening to conversation and occasionally partaking. Of intrigue was Rusty of Kuro5hin and Adam of Brian of Slashdot discussion development of site tools that will help a dynamic site fly, keep in mind all these tools are in Perl.
I think is it finally time to put together an edit entry tool for this tool. I have been using the MyPHPAdmin provided by my site host to go in and edit the entries when there are errors or updates needed. This has not been a great method when I lacking on sleep, as I have been here in Austin.
There are most likely going to be some small to moderate changes to this site in a few weeks. I have started working with modifying the left navigation bar to add more local and global elements (area of the site specific or applies to the whole site). The front page is also in dire need of re-contenting and possibly a small redesign. There is a CSS problem with font sizes here in Off the Top that I really want to address also. I may implement the comment system here soon, which has been running in test mode quite well. There will be a central photo page added in the very near future. A book list page for developers will also be added soon. The largest change will be to the links page, in that it will be changed from a hand built page to a content management system generated page.
The Visual Display of Quantitative XML on O'Reilly Net really rocks for me. I am really impressed with the presentation, but not nearly as impressed as I was with the ease of downloading and running the SVG plug-in in IE 6 on Windows and IE 5.1 on Mac OS X. Overal this is a great article as it not only walks through the how-to portion, but also offers insights into things that will make similar development go more easily.
Have you ever wish to build your own WYSIWYG tool in all within a browser? Mitchell Harper for Devarticles shows us how to build a DHTML WYSIWYG tool, aren't we glad we withed for it?
Personally I think I would extend the Hillman Curtis quote, "Web designer has to think of every pixel and the role it plays in brand" and extend it to the code behind the design. Every choice in the code impacts the display of the information or the way users, particularly with disabilities use the information. Sites that are well crafted have more usable information than poorly coded sites. Unfortunately, I have run across a lot of poor code of late, which the developers of the code believe everything is fine as long as it displays properly in their browser. The problem is not everybody has their browser. The poor coding not only adversely affects the display of every pixel on the page of other browsers, but provides poor usability of the information for the sight impared. The best step is to learn the standard code, learn to code my hand, learn what every tag and element does, learn to write a page efficiently, and most of all learn how to code for everybody in your user base. Lacking this we are just blindly coding in the dark and wasting our own time, the time those that thought they could use our information, and those who have to recode the information to make it usable.
Having watched the desktop publishing (DTP) trend "empower" people to design their own newsletters and brochures, I thought the Web would have followed in a similar growth path. DTP came to popular being in the late '80s with the advent of Adobe's PageMaker. Having formal training in communication design I realized the tool was powerful, but also dangerous. Moving into the workforce I watched the folly of the DTP trend. This powerful application when in untrained hands, could create output that was as far from what anybody would want being put out by a professional organization. I heard more than my share of executives screaming down corridors, "What is this cr*p". The DTP in the hands of the admin staff or the intern with out design backgrounds or training created about what was expected, garbage. DTP was quickly relegated to the hands of trained graphic artists, who turned out great products from the same application and often same machine.
What took four or five years with DTP is not being realized with Web development. Part of this may be Web development is more accessible and children can do it from home. The novelty of Web development has not reached the ends of the earth. Another driver that sets the Web apart is the embarrassment of people's children being able to build pages, which leads some folks logic patterns to the belief Web development/design is not difficult. Much like DTP, it is not difficult to build "something", but is does take a lot of work to build something good that is usable and maintainable. I still hear some executive yelling down the hall about the poor quality of a Web page, but the conversion of those developing sites to knowledgeable developers or turning the site over to experienced expert staff is still a slow transition. The glamour of the Web has worn thin, which is helping move the development to the hands of craftspeople and those with the passion to learn all the details.
I still have hope, actually I work in an environment that gives me great hope as the people with the power to say no do so for all the right reasons. The reasons are development that does not meet the minimum standards of a professional organization. The Web reaches far more people with the messages of our organization that the world prior. The Web imprints user's minds with the impression of a solid organization that cares about the information it handles, or it can do the opposite with equal ease. The experience and impression is in the hands of the professionals to see that these standards are met and adhered to. I am happy to work with not only professionals, but people with the passion to understand what is right to get the information to the people and get it there properly.
Web Reference guides us through efficient SQL calls to the database. Effiecient calls help speed the application's presentation and puts less of a demand on the server's resources.
I think a note of clarification is needed regarding the frames comments from the other day. I am a huge fan of the Content Management Bible and have been perusing it for a couple months (or so) now. The use of frames is not all bad, if used in a proper context.
One reason to use frames is using the browser client as an application interface and there are distinct sections with quasi-interrelated functionality. A mapping application (select any one of these elements on the page to see the use of frames - keep in mind there is a heavy use of JavaScript that requires a version 4.5 browser or higher). The application interface often has command elements that are essentially toolbars and definition selection elements that set the metadata layers of the information to be displayed. These toolbars direct the actions of the other frames or provide tools to be used in other frames (a zoom tool, etc.). The functionality in a toolbar is not an element of the map display and it should not be an incorporated element of the map as it has a much different functionality from the map display. Conversely, our users are familiar with navigation being incorporated into the Webpage and that is now a common and preferred construct. But, we are looking at an application being displayed in a Web browser, which requires a different mind set.
Another use of frames is in a controlled environment that has a plethora of distinct content items that are within a contiguous text, such as an extensive table of contents. Here the Metatorial CM Bible is a good example of when to use frames. There table of contents is a helpful information tool to quickly scan through the information to place the reader at distinct point in a larger body of text. The table of contents is a large (long) element of text that could work as an element is one distinct page, but that would require rebuilding those elements of the page with every snippet of information delivered to the browser.
Frames should be used when the distinct content elements require each other. The table of contents and the page display elements should not work with out the other components (if they can we really have to ask ourselves why we are using frames). If we can enter a page in the CM Bible without the table of contents the functionality of the site is broken. The navigation is not available and the assistive information (navigation and/or metadata elements) is not available.
The last item is to ensure that if a frame can stand alone as its own page, please ensure there are the needed navigational elements on the page. In the example that drove my frames rant (largely because the CM folks understand information and its need to be used, but the site breaks information use constructs we know from experience and research to be proper and needed) the thing that was disconcerting was each of the frame elements needed the other to provide complete information for the user. The user needs context. We need to provide the user a means to get to our front page or to other areas within our sites, because if they like our information we should offer them more. If we build a site using framed elements and these elements can be used on their own (no JavaScript sniffers to ensure the other frames are open as a requirement for displaying the content, or other similar technique) the content must have navigation elements (the footer is an unobtrusive placement) and really should have some branding or other statement of ownership.
We know that users of information have varied purposes and methods of using our information. We need to provide the users the tools to help the user provide this information. We are often proud of our information work, but if a user does not know it is us or we do not want to claim our work is decreases credibility.
We need to embrace functional information architecture to ensure proper information use. This bleeds in to user experience design, but understanding how information is used and the information interface is used must be integrated into the IA. Proper functional IA should keep improper use of frames from occurring. Functional IA would walk through a string of questions using a wireframe of a site and ask how the frame sections would interact. We would ask what information is lost if not all the frames function (a surprisingly common occurrence). We would ask if frames maintain context for the information. We would look at methods of insuring the whole of the frames remains so to provide proper navigation, proper context, and proper metadata to help understand the information provided. Not asking these questions is not being responsible to the information, those that collected the metadata and spent time understanding how the information is to be used, and is not responsible to the consumers of the information.
Metatorial offers a great selection of papers regarding content management on their site. The papers are great discussions on the subject of CM. The site also offer interviews, a great CM poster, and a promo for the Content Management Bible.
This site is unfortunately a great poster child for why one should not use frames. Frames make pointing to the desired content far more difficult than it needs to be. If people link directly to great content they lose the site's links to their other great resources. This site is horribly frustrating as there is great content wrapped in the absolutely wrong method for presenting great information to be shared. I guess folks can't be great at everything, I know I am not.