Category Archive » UI Programming

My Flash app: Part 2
[ December 01, 2003 | Permalink | 1 Comments | 0 TrackBack | TB URL ]

This is the first beta of my 'Learning Flash ActionScripting' project. As mentioned before, the purpose is to learn how Flash can be used from thru programmatic interfaces to make applications and do bare minimum work on the Flash stage. In particular this project uses the XML() object, event listeners and employs built-in components. The subject of the application is Edgar Lee Masters collection of poems titled "Spoon River Anthology" first published in 1916. [more...]


The Flash TextArea component doesn't support 'condenseWhite.'
[ November 19, 2003 | Permalink | 4 Comments | 0 TrackBack | TB URL ]

As of this writing, and as far as I know, in the Flash MX 2004 TextArea component, Macromedia missed an important detail when they created the TextArea component properties. You can say that the text area can be formatted by HTML, but that HTML formatting inherits the whitespace formatting as though a supersetted 'pre' tag was present. It makes for ugliness, and requires ugly workarounds (AFAIK). I sent email to the author of a good article that mentions this issue. In the article he said...

Now, a quick note on ignoreWhite: this normally excludes all spaces, linebreaks and carriage-returns from being counted when our XML is brought in to Flash (parsed), however I must admit I can't get it to work in my example or the Macromedia example I looked at earlier - you can see this for yourself by inserting a carriage return after one of the opening tags and then viewing the results in Flash - if anyone knows why this happens then please email me so I can amend this tutorial. I've left it in for the time being :]

I've been playing around with this, and have a few notes. First, condenseWhite would probably be the property to use/set as that is what is available in a dynamic text box (as opposed to ignoreWhite).

Unfortunately, it looks as though Macromedia did not implement that property in the TextArea component (and because components are compiled, you can't add that property support). If you remove all white space from the original xml doc (and you still have to use ignoreWhite while loading the XML) you can fix some of the display weirdness. That's a less than optimal solution though.

I may have to figure out how to write my own component, but that looks like it's out of my league right now.

<update when="November 22, 2003">

I wrote a function that deals with this problem...

	// This function kills any characters in the passed in string
	// that are considered to be white space. White space is defined
	// as anything *below* ASCII/Unicode character code 32.
	// We want code 32 because that's a space, and we want words separated, right?	

	function killWhiteSpace(theData) {
		var myNewString:String = '';
		var j:Number;
		  for(j = 0; j < theData.length; j++) {
			  if(theData.charCodeAt(j) > 31) {
				  myNewString += theData.charAt(j);
				  }
		  }
		 return myNewString;
	}

Use this function before you place your HTML into a TextArea component.

</update>


Starting over.
[ November 18, 2003 | Permalink | 4 Comments | 0 TrackBack | TB URL ]

When you decide to learn a new skill, and set your mind too it, and apply your free time to this new pursuit, it can be discouraging to find out that there is WAY TOO MUCH to learn.

Even with my JavaScript experience, and experience using graphics applications (eg, Photoshop and Illustrator), the Flash learning curve is relatively steep (for me), and that's mostly due to a few things...

Breaking Standards

Due to it's heritage, Flash sometimes departs from the ECMA spec to maintain backwards compatibility with old versions of Flash. That just plain sucks and requires memorization of these rules exceptions (all languages have these, but making an exception to support old players is annoying).

Also, I'm very used to the window, document and frames objects in JavaScript and need to map these to different names in the Flash paradigm (in my mind, I've assigned frames to levels; see below). Also, you need to accept the underscore notation used in Flash for built in properties in built in objects (ie, a movie clip's location on the "x" axis is read from movieClipObject._x).

The timeline

I have already complained about the timeline, but it's worth listing out here. This is one of those times when the metaphor is getting in the way and needs to be jettisoned.

Levels

"Levels are a stack of independent timelines that are movies (SWF) stored outside the main movie, and brought in with the loadmovie action." This is a pretty new concept to me. I'm very used to assembling a page from many small pieces (loosely joined?) and getting a cohesive result, but the idea of a document stack is something new to learn.

Object Oriented Programming (OOP)

JavaScript is object oriented, but in a loose way, and you can go a long way into your career without doing any proper object oriented coding in that language. When you move over to ActionScript 2.0, you really need to get on the OOP bus. This is mostly due to the fact that the flash environment is more readily disposed to OOP than web page authoring. This is going to be a good thing for me to learn.

My flash app: Part 1
[ November 14, 2003 | Permalink | 3 Comments | 0 TrackBack | TB URL ]

Philter's Flash/XML Tutorial was instrumental in getting me past the first bump in the ActionScript/XML learning curve. It's really not that hard at all, but the weirdo ways of dealing with things like symbol identifiers and addressing them has been a stumbling block. Getting past that and into the same-but-differently-named event handlers is going to be fun.

Right now, my current function for exporting and manipulating the XML doc looks like this...

	menuXml = new XML();
	menuXml.ignoreWhite = true;
	menuXml.onLoad = function() {
		menuItem = this.firstChild.childNodes;
		for (var i=0; i<menuItem.length; i++) {
			item = _root.attachMovie("itemClip", "itemClip" + i, i);
			item._x = 0;
			item._y = 21*i;
			item.itemLabel.text = menuItem[i].attributes.title;
		}
		item2 = _root.attachMovie("poemDisplay", "poemDisplayInstance", 10);
		item2._x = 125;
		item2._y = 0;
		item2.poem.text = menuItem[0].firstChild;
	}
	menuXml.load("spoon_river_anthology.xml");

I know, it's not very abstract. Also, I need to work on changing the content of the poem field based on which poen title has been clicked (which means I'll be using the onRelease() handler (instead of onmouseup() from my familiar worl of JavaScript). After that, the XML will get more attention because I have to add in the poem references (as I meantioned the other day, many poems in my selected body of work reference each other and better inform the user on the relatinships involved). That will manifest as another menu of sorts, and I'll need to use a Flash component to do that (another good lesson). Also, the poem field needs to be scrollable and that's another good lesson.

Here's a snippet of the (non DTD nor schema based) XML doc I've created so far for the project...

	<?xml version="1.0"?>
	
	<etext title="Spoon Riven Anthology" author="Edgar Lee Masters" 
			  published="1916" isbn="1-58734-032-1">
	
	<poem title="The Hill">
	Where are Elmer, Herman, Bert, Tom and Charley,
	The weak of will, the strong of arm, the clown, the boozer, the fighter?
	All, all are sleeping on the hill.
	
	One passed in a fever,
	One was burned in a mine,
	One was killed in a brawl,
	One died in a jail,
	One fell from a bridge toiling for children and wife-
	All, all are sleeping, sleeping, sleeping on the hill.
	
	Where are Ella, Kate, Mag, Lizzie and Edith,
	The tender heart, the simple soul, the loud, the proud, the happy one?--
	All, all are sleeping on the hill.
	
	One died in shameful child-birth,
	One of a thwarted love,
	One at the hands of a brute in a brothel,
	One of a broken pride, in the search for heart's desire;
	One after life in far-away London and Paris
	Was brought to her little space by Ella and Kate and Mag--
	All, all are sleeping, sleeping, sleeping on the hill.
	
	Where are Uncle Isaac and Aunt Emily,
	And old Towny Kincaid and Sevigne Houghton,
	And Major Walker who had talked
	With venerable men of the revolution?--
	All, all are sleeping on the hill.
	
	They brought them dead sons from the war,
	And daughters whom life had crushed,
	And their children fatherless, crying--
	All, all are sleeping, sleeping, sleeping on the hill.
	Where is Old Fiddler Jones
	Who played with life all his ninety years,
	Braving the sleet with bared breast,
	Drinking, rioting, thinking neither of wife nor kin,
	Nor gold, nor love, nor heaven?
	Lo! he babbles of the fish-frys of long ago,
	Of the horse-races of long ago at Clary's Grove,
	Of what Abe Lincoln said
	One time at Springfield.
	</poem>
	
	<poem title="Hod Putt">
	HERE I lie close to the grave
	Of Old Bill Piersol,
	Who grew rich trading with the Indians, and who
	Afterwards took the Bankrupt Law
	And emerged from it richer than ever
	Myself grown tired of toil and poverty
	And beholding how Old Bill and other grew in wealth
	Robbed a traveler one Night near Proctor's Grove,
	Killing him unwittingly while doing so,
	For which I was tried and hanged.
	That was my way of going into bankruptcy.
	Now we who took the bankrupt law in our respective ways
	Sleep peacefully side by side.
	</poem>
	
	<poem title="Ollie McGee">
	Have you seen walking through the village
	A Man with downcast eyes and haggard face?
	That is my husband who, by secret cruelty
	Never to be told, robbed me of my youth and my beauty;
	Till at last, wrinkled and with yellow teeth,
	And with broken pride and shameful humility,
	I sank into the grave.
	But what think you gnaws at my husband's heart?
	The face of what I was, the face of what he made me!
	These are driving him to the place where I lie.
	In death, therefore, I am avenged.
	</poem>
	
	
	</etext>

I don't even want to think about the actual UI of this thing yet. I should work on something consitent with the theme of the poems, but I'm probably going to be lazy and use Macromedia's "Halo" look n' feel.


More on learning Flash.
[ November 11, 2003 | Permalink | 6 Comments | 0 TrackBack | TB URL ]

Please forgive the comment recycling here, but this Leapster thing reaffirms my decision to pick up Flash as a web development skill...

I'm picking it up for the application development possibilities (as opposed to the design possibilities, which are imho, anemic).

I know javascript and because of that, I figured learning ActionScript would be easier. I've been doing pretty well so far, but have indeed encountered difficulties in wrapping my head around the way Flash does things. The timeline metapohre doesn't translate well to non-movie Flash projects.

More daunting though has been learning truer object oriented programming ("truer" for me equals using classes, methods and instances). This is a programming problem and not a Flash problem, so I can't fault the application for that. Getting on board with that will be helpful back in the Javascript world where I've never really done anything as fully abstracted as a class.

As a learning project, I'm working on an application based on Edgar Lee Masters' Spoon River Anthology which is a collection of interleaved poems about the townspeople of a small Illinois town, where everyone is dead. Each (relatively short) poem is kind of an epitaph and they usually make a reference or two to some other person from the town. You can then go look up their poem and read it to learn more about that person and their relationship to the referring poem/person. It's an interesting, if morbid, concept.

(For the record, I have an English degree and wrote a paper in college about Masters, which should explain why I'm using his anthology as my subject)

The idea of the application is to make reading the anthology easier, and the relationship matrix understandable, by showing the poem (with a dynamic text box, that scrolls if neccessarry) and a references box which lists who is related to the current poem. Also, there will be a full list of the people/poems to read so you can read it in linear style if you want.

I'm representing the anthology as an XML doc so I can learn the XML() object and it's methods.

I also have to do the design, but that's sort of ancillary to the main point of learning the system internals. It should be interesting.

Now, back to the Leapster; the opportunities and possibilities offered by that sort of product are two fold for the web developer who cares about usability and interaction design. Learning materials are all about interaction design and information architectures that are so well designed that they are transparent. "Leveraging" that thru development skills is good fun work that pays well. Too bad much of my recent work has been of the Systems Administration persuasion.


Learning Flash.
[ November 04, 2003 | Permalink | 5 Comments | 0 TrackBack | TB URL ]

I decided to learn Flash recently for various reasons...

• It's here to stay.
• Knowing it helps my career.
• We have use for it in my department (see number 2 above)
• I know JavaScript, so picking up ActionScript won't be hard.
• I know Illustrator, so picking up the Flash drawing tools won't be hard.
• DHTML can be a real whore sometimes.

The problem is, of course, the user interface for the Flash authoring environment. It's horrible, but has come a long way since the days of Flash 4. I've never been a fan of Macromedia applications UI's (because I'm really an Adobe guy at heart) and have mostly been struggling with where to edit this thing or that thing, where to define a script (or when to define a script vis-à-vis the Timeline).

I have to hand it to Macromedia for one thing though, their website has tons of material available for learning Flash. There's lots of sample files, articles, downloads, and manuals. Getting the PDF of the manual is free and easy, which I think is a smart thing for Macromedia to do (sort of a baiting tactic, but a warezing risk to be sure). All of that material is of course Macromedia centric (this thingy works great with this other Macromedia thingy).

Anyway, I have been looking for good resources out there and have bumped into the advert purgatory of FlashKit.com and the Moock's site. Any suggestions on where else to visit will be VERY welcome.


What do you think of your firstChild?
[ October 03, 2003 | Permalink | 4 Comments | 0 TrackBack | TB URL ]

I've discovered an inconsistancy and/or a bug in Mozilla's DOM implementation. Consider this simple unassuming HTML table which has it's id set to "ourTable"...

_Row_1_Cell_1_	_Row_1_Cell_2_	_Row_1_Cell_3_
_Row_2_Cell_1_	_Row_2_Cell_2_	_Row_2_Cell_3_
_Row_3_Cell_1_	_Row_3_Cell_2_	_Row_3_Cell_3_

The source of that table isn't anything weird and certainly isn't malformed HTML. Here's what the source of that table looks like...

<table border="1" width="50%" cellspacing="1" cellpadding="5" id="ourTable">
	<tr id="_Row_1_">
		<td id="_Row_1_Cell_1_">_Row_1_Cell_1_</td>
		<td id="_Row_1_Cell_2_">_Row_1_Cell_2_</td>
		<td id="_Row_1_Cell_3_">_Row_1_Cell_3_</td>
	</tr>
	<tr id="_Row_2_">
		<td id="_Row_2_Cell_1_">_Row_2_Cell_1_</td>
		<td id="_Row_2_Cell_2_">_Row_2_Cell_2_</td>
		<td id="_Row_2_Cell_3_">_Row_2_Cell_3_</td>
	</tr>
	<tr id="_Row_3_">
		<td id="_Row_3_Cell_1_">_Row_3_Cell_1_</td>
		<td id="_Row_3_Cell_2_">_Row_3_Cell_2_</td>
		<td id="_Row_3_Cell_3_">_Row_3_Cell_3_</td>
	</tr>
</table>

Now, using some JavaScript, let's start alerting things so we can see where Mozilla goes wrong (well, it does something different than Safari and Internet Explorer and I think it's incorrect). what we are going to do is alert the firstChild of the first row of the table. We do that in JavaScript by saying...

function whatIsThis(item) {

var myTable = document.getElementById("ourTable");

alert(myTable.rows[0].firstChild);

}

And then we call that function and pass in the name of the table we want to interrogate. In Mozilla you will get an alert box that says "[Object TEXT]" where as in Safari and Internet Explorer (I tested on my Win2k box for IE) you get "[Object TD]" and "[Object]" respectively.

If you go back up to the source of the table, and look at the firstChild of the first row, you very clearly see that there's a table cell there, and not the text contents of a random container. And for the record, accessing the table row thru getElementById and asking for it's firstChild returns the same result everywhere.

"Why is this important?" you ask. Well, if you want to use the DOM tools available to you for tracing around the DOM without knowing the ID's of everything, you can't do that with firstChilsd in Mozilla. That's bad. In my case, in a web application I'm working on, I have some HTML being written by a component in a very standardized way, and using ID's in everything is for more cumbersome than just grabbing the stuff that's in the firstChild of the firstChild of a table row. When we get "[Object TEXT]" back from Mozilla, there are no more firstChild[ren] available to us.

"So?" you ask, "why not use the cells[] array to trace into those table cells?" Well, the cell[] array is broken in Safari, and I'm trying to NOT write hopelessly forked (fucked?) JavaScript code for the sake of maintainability and editability by those who are more JavaScript challeneged than I am.

IMHO, Mozilla is obviously broken here.


Understanding the Eolas plugin patent.
[ September 12, 2003 | Permalink | 6 Comments | 0 TrackBack | TB URL ]

The subject of this post is a bit misleading, because I don't exactly understand the Eolas patent. This post is an attempt at grokking the situation.

First, Eolas claims that Microsoft "had stolen browser technology relating to plug-ins." this is, of course, a pretty vague statement. Then consider Microsoft's citation of CNN as being "an example of a site that uses Macromedia Flash--a technology many consider particularly vulnerable to the patent's claims--in a non-infringing way."

Is it the browser implementation that infringes, or the web site implementation that infringes? I'm not sure, but the Eolas patent is described by Eolas thusly...

First demonstrated publicly in 1993, this invention lifted the glass for the first time from the hypermedia browser, enabling Web browsers for the first time to act as platforms for fully-interactive embedded applications. The patent covers Web browsers that support such currently popular technologies as ActiveX components, Java applets, and Navigator plug-ins. Eolas' advanced browser technology makes possible rich interactive online experiences for over 500 million Web users, worldwide.

In the patent abstract, the following line indicates to me (a non-lawyer to be sure) that the devil is in the web site implementation...

The program object is embedded into a hypermedia document much like data objects.

Now, back to the CNN implementation and the way Microsoft suggests that web developers can avoid infringing code. It goes something like this...

One such option would move the data to the Web page itself, rather than pulling it from an external source.

If you haven't read the description of the CNN method, then go read it now... Notice any similarities? I do, and it's a very annoying process, that basically makes the data load external, but not external at the same time.

Anyone else have a clearer idea of what the deal is here?


My HTML isn't valid, oh well.
[ January 16, 2003 | Permalink | 6 Comments | 0 TrackBack | TB URL ]

Someone ran my site thru the W3C validator yesterday, and if this were grade school, I'd get an F on my report. I'm not really too upset about it for a few reasons...

1. This isn't grade school
2. This pages renders as intended in Mac IE 5.x
3. This pages renders mostly as intended in Mac Chimera
4. This pages renders as intended in PC IE 5.x thru 6.x
5. This pages renders mostly as intended in Mozilla 1.0
6. This pages renders mostly as intended in Opera 5 and 6
7. This pages renders as mostly as intended in Safari
8. This page is available as RSS 2.0, and more people get their IMX news from that source anyway
9. Perfectly validating HTML doesn't really get me that much
10. Rendering as intended is more important than validating for what this site is intended to do (ie, NOT be an XML/XSLT based web app)

The next rev of IMX will raise the bar in terms of validation, but I will only earn a B or B+ at best because some stuff breaks in Mac IE 5 if I go full bore HTML 4.01 strict, and dealing with that issue would likely force me to adopt drastic measures.


I still use html tables.
[ January 06, 2003 | Permalink | 18 Comments | 0 TrackBack | TB URL ]

Many bloggers are web developers, and many of them know of the value of separating content from its presentation. They know that tightly integrating your content with its presentation is a bad thing because making changes to the content or to the presentation then become difficult. MVC development environments help us out to a degree, but bloggers being what they are (front end oriented) like to abstract the UI as much as possible by using CSS and DIVs and the other homeopathic html remedies.

   » Don't follow this road blindly.

   » Don't get me wrong.

Fully abstracting your UI from its content takes skill and time. If you don't follow thru, you can negate much of the benefit you seek to create. Now stop and think. Do you even know what the benefit is that you are attempting to create? Will that value be worth the effort? Consider the price to performance ratio of taking time to fully abstract logic from presentation and content from presentation. Can you do adequate work (using html tables) without spending the time to fully abstract the UI (using divs and css)? Can you save the client money and meet their actual needs?

Actual needs. Don't ignore actual needs or forget them in your 'separate content from presentation' hubris. If you can intelligently analyze requirements and make decisions that minimize cost and maximize value, you are doing the right thing. Even if that means using html tables.

For the record: I'm not standards hater. I am a lover of my client's money, or my employer's budget and want to preserve my relationship with it. Sometimes you aren't doing yourself or the money holder any favors by jumping thru hoops, sometimes you are.

I know that doing 'the right thing' (ie, proper UI abstraction) can be easy, but it can be hard. Making mistakes and doing it half assed is really easy to do. Sure, you could go steal someone else's front end code, and make it really easy on yourself. But odds are that you have to develop a web app or web site that is original (imagine that).

My message is: Don't follow blindly, make decisions.


iframe and Doctype follies.
[ January 02, 2003 | Permalink | 15 Comments | 1 TrackBack | TB URL ]

If you apply a doctype to the content of an iframe that is greater than HTML version 3.2 (as in, 4.0 and above) and then view that iframe using Internet Explorer 6.0.2600 (the only browser I have seen this behavior in so far), chances are you will see a horizontal scroll bar. We all know that horizontal scroll bars are the herpes of web development, never quite going away, but still treatable. In this case, the treatment isn't so desireable.

Adding a doctype of HTML 3.2 will make the horizontal scrollbar go away. But, why were they there in the first place? I don't really know why, but the behavior is the result of the content taking the residence in the full size of the iframe, INCLUDING the vertical scrollbar. So, let's say I have an iframe that is 200 pixels wide and content that is set to take 100% of the space in that frame, well, the content won't be the 200 pixels minus the width of the vertical scroller, it'll be 200 pixels wide, making the horizontal scroller necessary to see the full content. Me no likey.

The solution is easy, but less than desireable. I can use the html 3.2 doctype declaration, or no declaration at all! I'm aiming at HTML 4.01 transitional compliancy for my redesign (why not XHTML you ask? That's a blog entry for another day) and I'd like to avoid mixing doctypes.

Thus concludes another chapter in the adventures of UI Development Boy (me).


I know HTML. Phear me.
[ December 31, 2002 | Permalink | 2 Comments | 0 TrackBack | TB URL ]

Several years ago my informal career manager (my brother) was quizzing me on the future of my skill set and where I thought I should be headed in my career. He's no fool and knows technology rolls over faster than a well trained dog. So while looking forward, and with sounds of XML working drafts in the background, he asked me...

Don't you think you should learn XML? Because HTML might go away soon.

To which I replied...

Well, there's currently billions of HTML documents out there in the world, and many of those will likely turn into XML someday, so learning XML will be a good idea. But HTML parsing web browsers are going to be around for a while, because that millions of HTML docs just don't evaporate suddenly.

To this day, I write HTML that's better than Dreamweaver's output, or any other gooey editor's output. I've read the O'Reilly XML book, and it is indeed a morass, but it's a morass worth learning, but ginsu HTML skills are still good to have.


Supporting Nav4 makes your app less durable.
[ November 05, 2002 | Permalink | 1 Comments | 1 TrackBack | TB URL ]

About two years ago I began adding a line to the Functional Requirements Documents I was writing that said something like...

Supporting Netscape Navigator 4.x represents a technical and business risk to the success of the Business Plan.

The reason I would add this is that double coding JavaScript routines, or using wrapper functions, represented a doubling in development time, resulting in increased costs to the client and a extended delivery times. Time is money.

This morning, I realized that my warning can and should contain another comment...

Supporting Netscape Navigator 4.x (Nav4) represents a technical and business risk to the success of the Business Plan. Implementing support for Nav4 will decrease the durability of the application be increasing the amount of code to maintain and the complexity of that code, for a browser that is rapidly falling off the browsing landscape.

Unfortunately, I still get projects where the question "who is the user base?" gets answered with, "Solaris users with Nav4." I'm at the point in my front end development career that those words anger me.


Making a month of work look easy. Good or bad?
[ October 26, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

First, me and the people I work with: I've been doing a front end revamp of a web app for the last month or so and am reaching the end of a major phase of that revamp. Things have been put in their place, context is more easily deduced and real estate has been consolidated. Some of the UI is even tucked away multiple directories down in the CVS tree all set up with containers for this and that so the Perl munkies can write pure Mason/Perl code and not worry about the vagarities of alignment of key:value pairs on the front end. They just need to send it out in the UI we have previously defined. (Very cool imho)

Onto the users: To them, the UI is the application. In the case of the web app I'm referencing, the API is really the application, and the web front end is a way to get at it and turn data ore into information ingots. More ways to get at the goodies under the hood will come soon enough. For now though, within the scope of the users who have power over me, it's the web interface that is the application.

Now, the point: Do the efforts of painting a better UI picture on a robust and maturing API reveal themselves to anyone but the UI developer?

[My coworkers read my blog and will no doubt have opinions on this. Do tell.]


RedHat UI sanity.
[ October 10, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

A Linux friend of mine sent me this URL to an interview with two UI people from Redhat. It's a pretty interesting read in terms of building a UI for a software product and how to structurally develop a UI architecture...

We can't have a situation where an application only works properly if it's running in a specific environment. (And for the most part we've avoided this problem.) Even if GTK+ or Qt went away tomorrow, we have to deal with VCL (OpenOffice), XUL (Mozilla), WINE, old Motif applications, and so on. The same is true on Windows, where I'm told there are multiple generations of the standard GUI toolkit, plus third-party toolkits such as OWL, Qt, and Swing.

The mere facts that RedHat people said that, and that they work for RedHat is encouraging. I can't agree more and is why I'm not a big fan of XUL (even tho it's a cool idea). The consistency they are aiming at is something that makes Mac OSX a good thing and why locking down the UI is not a horrible decision.


No HipTop for Anil. I have other reasons.
[ October 04, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

No doubt the T-Mobile hiptop 'puter named the Sidekick has a lot of geeky drool factor built in with GRPS, email, AOL IM, web browsing, and normal PDA'ish organizational electrickery. But, Anil seems to have a problem regarding the device...

you apparently took it upon yourselves to write software to specifically fuck up my website's display on your device. Do you hate me specifically, or just the internet in general?

He goes on to note that he failed to find any documentation about the browser on the device, but as Taco notes in his review of the device, the phone is auto-updatable "...so hopefully new and exciting features will roll out pleasing users with improved user interface." Let's focus on the browser issue, and one other fatal flaw; POP email.

The Sidekick comes with 16 megs. POP email means the email is downloaded to the device. POP email means that 16 megs gets gobbled up quickly forcing you to leave your POP mail on the server and get it elsewhere. I'm guessing this is the intended use, to check mail, not manage it on the device. It seems to me that IMAP support would be way smarter since you can download message headers and not the entire message and decide what to do with it from there.

So, here's a Sidekick 1.x (2.0?) wishlist...

• IMAP
• Standards based browser (Gecko lite?)
• Color screen
• Anything else?

Hey you, learn Mason.
[ September 25, 2002 | Permalink | 5 Comments | 0 TrackBack | TB URL ]

Hey you, learn Mason. I'm going to fail in doing justice to Mason here today. It's that great, really. However, it's not for everyone (sane people) and requires some knowledge of Perl. So, are you insane, and know some Perl? After all, one begets the other.

Why is Mason so great? First, if you do know some Perl, Mason can make your web application (or web site) development a lot easier by abstracting out the interface to arbitrary amounts of components. The Perl logic and database advantages should be obvious to anyone reading this here bit rag. The true value (imho, because I am a UI designer/developer) is the UI abstraction. But it's not complete abstraction, and I think that's a good thing.

Here's the description from the developer site...

Mason is a powerful Perl-based web site development and delivery engine. With Mason you can embed Perl code in your HTML and construct pages from shared, reusable components.

It's true! And like I said, not full abstraction is a good thing. Most of the components I work with have Perl at the bottom of the file declaring stuff, referencing a database and making nice and tidy objects for me to reference. We load up an object called "$user" which has all sorts of goodies inside of it such as phone numbers, addresses and titles. Being a JavaScript writer (another job for insane people) I'm used to object hierarchies and extracting values from them to do sleight-of-hand UI tricks. No new concepts to learn!

Another Mason nicety: We have a suite of form element components with other UI elements wrapped around them for formatting in a standardized way. Those components can have data passed into them from other components to populate up the form elements. As in, we pass in the "name" of the element, it's "value" and any onclick/onsubmit handlers. The component that passes in these variables is written in pure Perl/Mason. So, if I have done my job as a Mason and UI developer, I can prevent the Perl coders them from writing ANY UI code. That's good.

I've only scratched the surface here so I'll mention one of the other great things, "dhandlers". The documentation says...

What happens when a user requests a component that doesn't exist? In this case Mason scans backward through the URI, checking each directory for a component named dhandler (``default handler''). If found, the dhandler is invoked and is expected to use $m->dhandler_arg as the parameter to some access function, perhaps a database look up or location in another file system.

The part I really like is the recursion, using the URI, to figure things out. This allows you to create URLs that don't actually exist, but are bookmarkable and will cause Mason to use the dhandler to execute whatever Perl code you want to return whatever you want (be it HTML< XML or even CSV). Bookmarkable resources = web services. mmmmmmmmmmmm, web services...


Obsolescence is a relative term.
[ September 12, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

No doubt that you, my three or four readers, have heard about Zeldman's Neilsonian like decree that 99.9 percent of web sites are obsolete. I'm guessing that in Zeldman's view of the world, this is true (and that view may be clouded by efforts to sell books), but that's not my view. If it was, this site would be obsolete with it's tables based layout and gratuitous use of spacer.gif's.

The folks I work with often write their own little screen scrapers when data isn't exposed to them in any other way. Is the horribly coded website that they are scraping obsolete? Anything but. But, don't get me wrong, I like code that validates against it's DTD, and I love standards (because I hate double coding) because it all becomes more reusable and portable as requirements inevitably change. But this doesn't make old crappy code obselete, it just makes it more expensive to work with, and that is what's important in the real world, MONEY/COST. Don't forget that.


Deprecate this.
[ September 06, 2002 | Permalink | 2 Comments | 0 TrackBack | TB URL ]

So, <br> has been deprecated in the proposed XHTML 2.0 spec in favor of the <line> element. And while I can appreciate the tendency to lean toward logical rather than physical styles, the deprecation of <br> for <line> leads to an inflexibility...

The line element represents a sub-paragraph. It is intended as a structured replacement for the br element. It contains a piece of text that when visually represented should start on a new line, and have a line break at the end.

Um, I use <br> because I want ONE break, not two. If I wanted two, I'd use a block level element, like a <div>. I must be missing something here.


Second O'Reilly DHTML book on the way.
[ July 31, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

O'Reilly has finally put out the word that the DHTML Bible, aka, Dynamic HTML: The Definitive Guide. It's not going to be cheap ("$59.95 US est.") but is a full 50% fatter than the current 1000+ page tome. /me drools...

Dynamic HTML: The Definitive Reference, Second Edition, is an indispensable compendium for web development. The new edition has been updated to include complete reference material on the latest specifications, including HTML 4.01, CSS Level 2, DOM Level 2, and JavaScript 1.5, as well as the latest browsers, Internet Explorer 6 (Windows), Internet Explorer 5.1 (Mac), Netscape Navigator 6 and 7, and Mozilla 1.0.

Is my O'Reilly bias showing? I sure hope so. And while we're on the subject of O'Reilly and bias, here's a blog item (first seen via camworld) from the man himself on MSFT, AAPL and they way things are.


You need a crutch when your leg is broken.
[ June 18, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

ScottAndrew wonders what he really feels about JavaScript crutch libraries. I don't. I like them, welcome them and hope people learn from them. Personally, I find myself in a fire drill environment where a solution to a problem has to come as quickly as possible (sound familiar?). I keep a directory of old JavaScripts on my machine as reusable code libraries, but of course, as time goes by, they go stale, and Murphy's Law says I'll need the most stale script on a moments' notice. If I can get that working with minimal effort and deliver reliabel, functioning code, then I've put out the fire. When I have time, I go back to make the code clean, elegant and proper. I'll call this being resourceful.

Scott's point is not lost on me though, and I agree that correct, modern, validated, tolerant and gracefully degrading code is a best practice. Sometimes you just have to fill in the cracks and repave later (time and budget permitting).


Flash could be good for web applications.
[ March 14, 2002 | Permalink | 1 Comments | 0 TrackBack | TB URL ]

I couldn't resist to post my response to a message on the WebDesign list...

at 3/14/02 8:28 AM by Zak McGregor wrote:

> http://news.com.com/2100-1040-849981.html
> 
> "We've been looking at how people work on the Internet, how people use
> Internet applications, and what we saw was that...HTML was breaking down
> in a lot of cases," said Eric Wittman, Macromedia's director of product
> management for Flash. "
> 
> So I gather that Macromedia is gunning to replace an open standard with
> a proprietary technology, and wants to rid the world of HTML? This seems
> absurd, but it's not April 1st yet. 

Be sure to keep within context here. This is in reference to *web applications*, not normal, content based, web sites.

I have worked on a few complex web applications, and HTML was indeed breaking down on us. The reason being that Netscape 4.7 is a completely different browser to code for than IE (which we all know) and both have odd bugs that cause application crashes. Quite often, HTML and some incredibly sophisticated JavaScript was just barely able to meet the business needs of the client.

If we could eliminate the (business and development) liability of wildly inconsistent DOM, HTML and JavaScript implementations, we would have a massively easier (and cheaper!) way to built a web app that could be called robust. Also, not having anything resembling a client side IDE is a problem for serious web app development. Using the Flash authoring kit (or LiveMotion) can mitigate that problem to some degree.

> What does this mean for the vision of client-independent content
> delivery? How has Macromedia addressed it's inherent weaknesses when
> compared to html, for example word weighting, full indexability [sic], the
> ability to display on devices other than windowed GUIs, the inability to
> link to specific information in Flash, bookmarking issues, printing
> issues, etc?

When it comes to the web applications I have worked on, issues like "full indexability" do not matter. What does matter is predictable results in a highly complex environment. In me experience, DHTML can't provide that.

I welcome any technical advances in Flash technology to make web apps more robust, usable, and "codeable." I don't feel like that will be any threat to (X)HTML's future.


Good Flash = lots of time.
[ January 28, 2002 | Permalink | 0 Comments ]

I sincerely believe that Flash has serious potential as a web application platform (for the display layer anyway), but you can't deny that it also has tons of entertainment potential too. But who has the time to do Flash sites like these? Not me.

• eugene the marvelous crooning child
• The Mario Twins
• Praystation
• Levitated Core

O'Reilly makes it ok to code.
[ December 08, 2001 | Permalink | 0 Comments ]

The O'Reilly series of technical books is, imho, the best money can buy. When I saw the book for Flash ActionScripting, I thought to myself 'now it's ok to learn that.'

The JavaScript book has just been updated and was written with the help of the inventor of the language. The DHTML book is simply invaluable (even if the first and only edition is getting long in the tooth). If you are a budding web designer and find that you need to mess around coding, do the right thing and go O'Reilly.

They even give freebies on their website, like this article about the DOCTYPE element in HTML that has more control over things than you might think.