Mar 09

MozMill 1.1 UI Overview

During the Open Design session at Mozilla with Aza we were informed that we could load a HTML file with a Chrome URL, allowing me to rebuild the MozMill UI a bit more like a web page instead of using the XUL constructs that I had been struggling with. Granted it feels a lot more like a web page than it does a desktop application, but the speed that I can build new UI features by using libraries like JQuery UI have made it worth it.

The combination of writing content style HTML, and the good advice we received have come together into what I feel is a pretty usable user interface. Granted this is the first revision and will probably continually be refined to become even more user friendly, but from 1.0 to 1.1 it is a vast improvement.

MozMill Editor

Improved Editor

The first major improvement is the implementation of a full featured code editor named EditArea.

We have been keeping our eye on Bespin, which we will look more into integrating when it is a bit more modular.

For the meantime EditArea does a great job, and was *relatively* painless to integrate.

Some of the features include:

  • Multiple file editing
  • Syntax hilighting
  • Full Screen mode
  • Adjustable font properties
  • Jump to line numbers
  • Search and replace
  • Automatic tabulation
  • Toggle hi-lighting
  • Toggle edit modes

EditArea implements execCommand similar to the implementation in Midas.

Reorganized Menu’s

Part of the move from XUL involved no longer relying on the toolbox, so we have reorganized the menu’s into dialog’s (don’t worry most functions have a keyboard shortcut if you are one of those people that doesn’t want to deal with that extra click).

This cleanly displays all the available options, and doesn’t clutter up the main UI. This also provides space to easily add new features that fall into these logical spaces in the future.

Test Dialog

File Dialog

Options Dialog

Improved Inspector

There was a lot of frustration when it came to getting the results from the inspector into the editor, some of this had to do with the non editable default nature of the elements we were using to draw them out in XUL, but the integration of the feature into the IDE became very messy and confusing.

This creates an obvious separation between the rest of the UI and the inspector feature and puts helper features out in front of you to simplify the process by dumping to the clipboard and then moving you to a focused editor window.

Improved Output

The output UI has been completely revamped to give you the most important information quickly, but allow you to navigate down an expandable tree to explore the output of the exception.

All of the information in the output divs can be easily selected and copied to stick in bugs etc, but also saves you a trip to the error console as it should encompass all of the information being thrown in the error object, serialized and organized into a more readable format.

Thanks to JQuery UI’s information and error boxes I was able to tweak the CSS to make some relatively attractive, but more importantly, informative UI that should quickly give you the status of your test run.

More Information

Thanks everyone who logged bugs!

Jun 08

IE Web Development Tips

As a web developer you are probably aware of that sinking feeling in the pit of your stomach that you suffer when posed with the idea of testing your freshly written JavaScript that works perfectly in FireFox.

For years now, we have had to ‘suck it up’, and pour a glass of scotch to get through an afternoon of testing in IE. As I am now a Web Developer at Rearden Commerce who currently caters to an audience of enterprise users instead of your standard bay area geek population — I have to make sure everything I commit works nicely in IE.

Last week after a few hours of IE testing, and dirtying my code I worked so hard to perfect and refine with alerts everywhere I decided that there HAD to be a better way to do this. I went ahead and spent many hours searching the web, installing everything I could find that promised to make IE development easier and happily I can say — it was a success.

First and foremost however, there are a few tips I can give you right off the top that will make your life easier. Before you take the plunge into line by line alerting, go through your code and do the following;

* Remove unnecessary commas in your data structures:

( FF ignores this one, but IE will give you an error that isn’t helpful )

var superNinjaObject = {
me: 'adam',
home: 'oakland',

* Don’t try to access characters in a string as if it was an array:

( Works in FF, but IE will simply give you undefined and not tell you a thing )

var myString = 'Welcome to the Jungle';
$('mynode').innerHTML += myString[14]; //Broken in IE
$('mynode').innerHTML += myString.charAt(14); //Compatible alternative

Now we can get to what you are really interested in, the new tools:

1. Internet Explorer Development Toolbar

Get It: Microsoft Downloads

This is Microsoft’s best stab at a firebug equivalent. This gives you all the flexibility you need to inspect the DOM tree, look at CSS, Scripts, Images, Network etc. To put it simply, it makes IE development something you can swallow. I can’t image going back to IE development without this. Unfortunately it is missing two things, the first is the absolutely necessary JavaScript shell. This can be solved by using the IE JS Bookmarklet that you can find at blog.monstuff.com. Add this to your favorites and then whenever you need a JS shell, pop this up and hack away ( I agree it would be nicer if it was built in ). The second is the ability to set breakpoints and step through your code debugging and introspecting objects and variables. I do have a solution for this, see new tool number

2. Visual Web Developer 2008 Express Edition

Get It: Microsoft Express

This is the solution to your break pointing, stepping, introspecting needs. The way you use it is a bit awkward, but it does complete the development experience. To use this you need to create an empty web project and then start debugging. This will launch IE and bring you to a blank server page off the local MS web server instance. At this point you can go ahead and plug in the URL of the app you are wanting to test. Additionally if you have set any ‘debugger;’ statements in your source it will pick that up and automatically ask you if you want to start debugging there, or continue on. When you stop the debugging session in VWD it will kill your browser, so beware if you have to navigate to some deep point in your app you are probably going to get frustrated if you write buggy code. :) At it’s 1.4 Gb space requirement it’s hardly a comparison with firebug — but it’s certainly a step up from alerts all day long.

3. Microsoft Script Editor

Get It: Jonathanboutelle.com

If you don’t already have it installed, a good midpoint between nothing and Visual Studio Express is the Microsoft Script Editor which comes with office 2003, heres a video on how to use it, Video. Thanks for the feedback blogosphere.

I hope this made your life at least a small amount easier, happy IE developing.

Get Adobe Flash player