Categories
Diversity JavaScript

Gewgaws can be accessible. Valid, too.

One of the DHTML (Dynamic HTML) effects not built into my own libraries is a fish-eye effect. Those of you who have a Mac will know the effect I’m talking about: when you move your mouse over a menu bar, the items expand but in a way that emulates a ‘fish-eye’ magnifier.

This isn’t a trivial effect to create. You not only have to capture the web page reader’s mouse movements, you also have to size objects in relation to each other and the mouse. Luckily, the popular Ajax library Dojo Toolkit, created by a consortium of interested developers has just such an effect.

Though Dojo has documentation, it’s coverage is like Wikipedia’s coverage: it’s added by interested parties, and as such, there are gaps in how to use some of the library objects–including the Fisheye Widget. However, there are plenty of demos, includin one for this object.

To use this functionality, according to the demo, you create a series of div elements: one outer, one that acts as control, and several inner (for each menu item). You then add Dojo class names, as well as element attributes providing information for the menu caption, source file for the icon, minimum and maximum image sizes and so on. The markup in the demo is as follows:


<div class="outerbar">

<div class="dojo-FisheyeList"
	dojo:itemWidth="50" dojo:itemHeight="50"
	dojo:itemMaxWidth="200" dojo:itemMaxHeight="200"
	dojo:orientation="horizontal"
	dojo:effectUnits="2"
	dojo:itemPadding="10"
	dojo:attachEdge="top"
	dojo:labelEdge="bottom"
	dojo:enableCrappySvgSupport="false"
>

	<div class="dojo-FisheyeListItem" onClick="load_app(1);" 
		dojo:iconsrc="images/icon_browser.png" caption="Web Browser">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(2);"
		dojo:iconsrc="images/icon_calendar.png" caption="Calendar">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(3);"
		dojo:iconsrc="images/icon_email.png" caption="Email">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(4);"
		dojo:iconsrc="images/icon_texteditor.png" caption="Text Editor">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(5);"
		dojo:iconsrc="images/icon_update.png" caption="Software Update">
	</div>

	<div class="dojo-FisheyeListItem" onClick="load_app(6);"
		dojo:iconsrc="images/icon_users.png" dojo:caption="Users" >
	</div>
</div>

</div>

It’s an interesting approach to take: embed the necessary information as tag attributes, so that the person doesn’t have to touch code. However it has two major drawbacks: it doesn’t validate, and it’s not accessible.

Dojo, like many other of the new Ajax libraries, make use of custom attributes on standard HTML and XHTML objects, which don’t validate as either HTML or XHTML. In addition, the menu is JS driven, so a person who doesn’t have JavaScript enabled won’t have access to the menu. Not only JavaScript driven, it’s also mouse driven menu, which makes it unusuable within text-to-speech browsers.

Modifying the code so that it validates is a bit tricky, but doable. What is required is removing the tag attributes for the elements, and adding these using the DOM, or Document Object Model, API.

I have six menu items, which means removing the custom attributes for one controller and the six menu item div elements:


<div class="dojo-FisheyeList" id="controller">

        <div id="menu1" class="dojo-FisheyeListItem">
        </div>
...
        <div id="menu6" class="dojo-FisheyeListItem">
        </div>

</div>

In JavaScript, I use the DOM setAttribute to re-set these custom attributes. The following code re-sets the attributes for the controller object:


  var cont = document.getElementById("controller");
  cont.setAttribute("itemWidth","60");
  cont.setAttribute("itemHeight","100");
  cont.setAttribute("itemMaxWidth", "200");
  cont.setAttribute("itemMaxHeight", "300");
  cont.setAttribute("orientation","horizontal");
  cont.setAttribute("effectUnits","2");
  cont.setAttribute("itemPadding","10");
  cont.setAttribute("attachEdige","top");
  cont.setAttribute("labelEdge","bottom");
  cont.setAttribute("enableCrappySvgSupport","false");

These attribute settings are exactly as they were found in the tag attributes, other than altering the image sizes to fit my own GIFs.

For each of the menu options, again the element is accessed by identifier, and attributes added with setAttribute. The following sets the attributes for the first menu item, but all other menu objects are modified using the exact same code (but different images and captions):


 var menu1 = document.getElementById("menu1");
  menu1.setAttribute("onClick","load_page('http://learningjavascript.info')");
  menu1.setAttribute("iconsrc","/dotty/dotty.gif");
  menu1.setAttribute("caption","Learning JavaScript");

Since Dojo requires these attribute settings before its functionality, and it processes the data on page load, the function that contains the attribute setting needs to be called right after the div elements are created in the page. One way is to embed a script block calling the function in the web page right after the div elements are created:


<script type="text/javascript">
//<![CDATA[

setMenuProps();

//]]>
</script>

(Notice the use of the CDATA section surrounding the script? This, also, is required in order for the page to validate as XHTML.)

Once the attributes are set, the Dojo fisheye menu loads cleanly, without having to use custom attributes. But something’s still missing: attributes that are required. Each img tag requires an alt attribute, which is a legitimate X(HTML) attribute, but one that’s not provided.

I explored the Dojo code and tried a couple of alternatives to add attributes for the images, but nothing worked. There’s also nothing in documentation. So, back again to my own custom code.

Unlike setting the initial attributes, the alt attribute needs to be added afterDojo has done its work and created the menu. Dojo captures the window.onload event, which I also needed to capture. However, I had to do so in such a way as to not ‘break’, or override Dojo’s event handler.

I needed to use the DOM again, but this time to attach an event handler on the window onload event, chaining it with the Dojo event handler. The following code does the trick:


function addWindowOnLoad(func) {
   // test for object model
   if (window.addEventListener) {
      window.addEventListener("load",finish,false);
   } else if (window.attachEvent) {
      window.attachEvent("onload", finish);
   }
}

addWindowOnLoad(finish);

The finish method then accesses each image in the page, checks for class name, and when it matches the Dojo class name, checks the source attribute on the image. Based on the text, the related alt tag value is set:


function finish() {
  for(var i = 0; i 

The page now validates as XHTML transitional. Thought it takes more code, it’s preferable than just blowing off XHTML as ‘not useful’, or unimportant. We haven’t walked three steps forward in our use of web standards the last decade, only to take two steps back now for the sake of a little sizzle.

Even if we decide to blow off valid markup, we can’t justify blowing off accessibilty (of which valid markup is one component). A pretty or cool effect is not worth putting barriers around our pages. Unfortunately, though, accessibility is both easier and more difficult to implement.

The simplest accessibility option is to provide a NOSCRIPT block with content to display if JavaScript is disabled. In this case, a straight menu with hypertext links around images is all that’s needed:


<noscript>
<a href="http://scriptteaser.com/learningjavascript/"><img src="/dotty/dotty.gif"  
  alt="ScriptTeasing News" /></a>
...
</noscript>

Unfortunately, other accessibility issues aren’t as easy to resolve. A truly accessible menu needs to be keyboard sensitive for many text-to-speech browsers. Adding this into the Dojo menu is going to take additional thought. In addition, the behavior of the menu is off with Internet Explorer 6.x (the entire menu doesn’t display until you move your mouse over the bar).

Then there’s the issue of the size of the Dojo libraries. There’s a noticeable delay loading this page with Dojo’s large code base in addition to mine, just to create a visual effect.

Sometimes, though, you want both the sizzle and the steak. I’ll return later with more on whether I’ll keep the Dojo fisheye menu, and how I’ll resolve the last issue of accessibility if I do.

Categories
Technology Weblogging

Tipping the Apple cart

Recovered from the Wayback Machine.

There are some high profile folk in the technology and weblgging communities who are quitting Apple products: Mark PilgrimCory Doctorow, and even Tim Bray is giving it a thoughtJason Kottke asks whether Apple should be worried. He wonders whether these acts could be a foretaste of what is to come:

Nerds are a small demographic, but they can also be the canary in the coal mine with stuff like this.

Is Kottke right? Are these men the canaries in the mine: harbingers of deep and serious times ahead for Jobs and company?

I doubt the average Mac user has heard of Mark Pilgrim, or Cory Doctorow, or even Tim Bray. Kottke’s point, reiterated by Tim O’Reilly, isn’t so much that, “Look here at these famous people, they’re leaving Apple” or even, “look, these are famous people”, as much as these were longtime fans of the Apple/Mac environment. If they, stalwart and heavily invested champions, are considering leaving, will Bob and Alice, Ted and Carol be far behind?

Yes, and no.

These gentlemen are also heavily invested in open source and open standards, which has and will continue to influence their decision. The average Apple customer, though, most likely doesn’t care about source or standards; no, not even when it impacts them. Lock-in? What is lock-in. Lock-in is having to make a choice and living with the consequences. Heck, the average consumer is used to having to make that crucial choice: VHS or BetaMax; iTunes or MP3; marry Paul or hold out for John; Macy’s or Gimble’s; Pepsi or Coke.

To the average consumer, lock-in is equivalent to competition and isn’t competition supposed to be a good thing? As for the average tech, he or she doesn’t know how to communicate the awfulness of lock-in—well, other than acts such as switching to Ubuntu.

But then, a geek switching to Linux isn’t necessarily a new thing.

“Hey, I’ve switched to Ubuntu.”

“I find I like the Brazilian coffee beans, myself.”

“No, Ubuntu is a form of Linux.”

“Linux? Weren’t you already using Linux? I thought all you geeks used Linux. What were you working with before?”

“A Mac.”

“Mac? As in Apple? With all the aqua stuff?”

“Yup.”

“Wow. Well, aren’t you precious. Little wittle command line scare the big bad geek?”

“Hey! I’ll have you know that the Mac operating system is built on BSD, a hipper version of Unix.”

“Yeah, but that’s like driving a Barracuda with an automatic transmission.”

Geeks leaving Apple for Ubuntu isn’t a Sign. Even famous geeks leaving Apple famously isn’t a Sign. Geeks leaving Mac for Linux is just another example of someone making a choice.

Now if Uncle—the man who can’t figure out how to use his toaster without burning PopTarts—leaves his Mac for a Linux box, well….next thing you know, Microsoft will replace Steve Ballmer with a black woman, and Sony will decide that art demands to be free.

In the meantime, my own Why Switch ad. Just tap the apple, wake up the worm.

Or, if you have time and bandwidth, the best version. Warning: Quicktime mov file, huge sucker. And one for your little iPod, too.

Quicktime 7 required

Categories
Web

The new Hello World

Recovered from the Wayback Machine.

Programmers have traditionally created as their first application in any language or environment the “Hello World” application. This is an application, small as possible, that outputs the words, “Hello World”. Wikipedia has a nice entry on Hello World, including the first known instance of using this now ubiquitous right of passage for programming.

The thing with “Hello World” is that it’s a small sentence, and thus isn’t the best of tests when trying out a content system, such as text editor, weblogging tool, and so on. Enter the Lorem Ipsum generator, the Hello World of writing. Wikipedia also has a nice entry on this.

Categories
JavaScript

Eclipse: beyond the geek

I’ve been spending time today with Eclipse, the popular development tool used primarily by Java developers. I’m using Eclipse in my J2EE development because there’s a plugin that enables EJB development for JBoss, and another plugin that enables web servlet development, and yet another that allows me to interface with a SQL Server database, and even a plugin to connect with Subversion. These are all professional development tools, more or less. Yet Eclipse is not just for the pros, or the geeks.

It’s easy to install, with installations for Unix, Linux, Mac, and Windows. I had to use gunzip and tar to unzip and expand the package for the Mac, because the machine I’m using is my older Mac; it doesn’t have the modern unzipping tools of the Tiger machines.

Once Eclipse is installed, then the fun begins. You can add any number of plugins.

 

For instance, if you work with JavaScript, there are several JS plugins, and even some Dojo-based AJAX plugins. Some of these may cost, others are free. One of the more popular is the Web Tools Plugin environment, which is free and sets your Eclipse up to develop almost anything web-related.

Eclipse was installed on my PC for work, but I wanted to explore the use of Eclipse as a tool for JavaScript developers. I installed it on my Powerbook, and then used the automated update and installation program built into Eclipse to add the Web Tools. How do you do this? You’re going to laugh, it’s so easy.

First, click the Help menu item, then Software Updates -> and then choose Find and Install. From the window that opens, click the Search for New Features to Install feature, and then click Next.

In the page that opens, there’s a box listing out what remote sites to check for new and updated software. I then click New Remote Site, and in the dialog box that opens, I added in:

Name: Web Tools

URL: http://download.eclipse.org/webtools/updates/

I clicked Finish and when given a new dialog with a list of features to install, checked the box next to the Web Tools option, and then clicked the Next button. Following, I’m asked to agree to the license terms, and from that point on, Eclipse not only downloads the tools, it also downloads all the pre-requisites needed for the tools to operate. That’s it — when it’s finished it asks to re-boot and when you’re finished, you’re ready to use the new functionality.

I created a new project by selecting File->New->Project->Other. From the list that opened, I just selected Simple, and then gave the project a name: test. Based on whatever project type is picked, Eclipse adds any supportive libraries and generated files, listed underneath the project name in the left pane.

I created a new JavaScript file by again selecting File->New->Other. From the dialog that opens, I clicked Web, and then selected JavaScript. Since I’m saving my creativity for my work, I again used the name test to name the JS file: test.js.

At this point, the new test.js file shows in the left pane, and the open file ready for edits is shown in the center panel. I type in whatever JavaScript I want. As I add new program objects, like variables, they show in the outline panel on the right. If I use a built-in object, like Math or document, when I type the period to access an object property or method, a popup window opens listing available options, and even the browser icon associated with the option.

 

When I’m ready to preview the functionality, I click the Preview tab that shows at the bottom of the center edit pane; the preview emulates a browser page.

Being a programmer I know that if one plugin is good, dozens are better. Shopping around, I installed Eclipse plugins for PHP (PHPeclipse), database access (DbEdit), and a CSS editor.

The latter was a commercial plugin from JointLogic, downloadable for trial for 30 days. Once installed (using the same procedure I used to install the Web Tools), I created a new CSS file using the same approach as I used with the JS file. I then began to add styles to the new stylesheet file, and as I added new elements, they would show in the outline pane in the right.

I also selected the CSS style view pallet for the plugin by selecting Window->Show View->Other and then selecting JointLogic Web Tools and then the CSS Styles. The view is listed as a tab in the bottom pane. When double clicking on an item in the outline view, such as the H1 header, a dialog opens giving options to define this type of HTML element.

 

After selecting the changes, and clicking OK, the edits are neatly added to the CSS document.

Eclipse isn’t an all in one tool, and wouldn’t be for folks who don’t like to tweak styles, HTML, or script. It requires a Java runtime environment, and it’s not small. But it is free, it is modular, and it isn’t just for geeks.

Thought you’d all enjoy a new toy to play with.

Categories
Programming Languages

Dabble

I agree with Sam Ruby: a successful tech is a diversified one. You can’t always depend on a new millennium to justify sticking with one and only one programming language.

This last week I worked with Java, JavaScript, PHP, Python, and Ruby. I had been on a long hiatus from Java after the end of the dot-com era, but now I’m back and plan on sticking it out with the language. Yes, even unto J2EE.

I also agree with Michal Wallace: you are more likely to have an easier time getting work if you focus on .NET than Python. In some ways, I think that the interest in Ruby has slowed the interest in Python. Sure you can work with both languages: but why would you want to?

In St. Louis, the demand is for .NET (VB or C#) or Java. That’s it. I mean, that’s really it. Most of the other work in PHP or Python or Perl is off-shored.

When I move to the northwest, I imagine I’ll either need to get back into .NET or brush up my C++ skills, in addition to the Java. If one has up to date C++ skills, one can usually find work.

As for JavaScript — every web developer should be proficient in JS. Eventually you’re going to want to validate a field before sending it to the server, or have to muck with cookies. There will always be someone somewhere who will say, with breathless excitement, “What about AJAX?” JS is ubiquitous.

PHP is also ubiquitous, but there just isn’t the work for it. Nor Python. Perl’s fading. I have my eye on Ruby, though.