Wednesday Apr 02, 2008

Web Prototyping with NetBeans

For the best Ajax-ready environment to support rapid development, its got to be NetBeans 6.0. I think. I mean, I've not actually used it yet, but I do have a need to build some prototypes for dynamic web frameworks that include little widgets and JSF bits and pieces (probably) to enable me to look cleverer than I actually am, which, unsurprisingly, isn't difficult.

I've not settled on a development environment since I started trying to use them in earnest a good few years ago. Most of the things I've used to try and support rapid prototyping are not really IDEs at all, but applications that just do one thing, meaning I end up using 3 or 4 of them and try to stitch everything together rather unsuccessfully at the end. If I was being really pedantic, which I am, I'd say the best development environment I've ever used for web prototyping, where the web part is actually a web part and not just a photoshop part, was XEmacs. I know some of you reading this are going dewy-eyed at the very mention of it, before you get back to work on Dreamweaver.

The problem with most applications, IDEs, or whatever toolkits I've come across, is that they invariably do at least one thing that constantly irritates me. Not the kind of thing that irritates me that you can turn off in an options screen, but the kind of thing that irritates me because its intrinsically the way the application does what it does, whether its the cumbersome previewing methods, or the sublime adherence to a doctype declaration I didn't specify, or even just having windows with fat, ugly borders. Actually, that last one is the kind of irritant that would bug me the most.

So, I'm hoping that NetBeans will be something I can call my friend. If not, its back to XEmacs, a gin and tonic, and a long night of ctrl-c, ctrl-v and ctrl-bladder, until I've hacked together a product finder that surfaces on not just product gateway pages, but the whole of the moon.

AddThis Feed Button AddThis Social Bookmark Button

Technorati Tags:

Listening Post: The Prodigy: Poison

Wednesday Mar 19, 2008

IETab for XHTML Traps

You'd think I would check. First rule of web design and all that. I mean, we extensively test our web design components against all the platform and browser combinations out there, and Andrew and Greg are constantly redefining CSS elements so that we maintain a consistent style, whatever you're using to connect to us.

But that can't save me from being a lazy arse. I like to put images in blog posts to illustrate points, or just to make myself less uninteresting than I am. I also like to have them aligned left or, usually, right, with text wrapping around them. This is from the HTML 1.0 handbook, right? So I was rightly ashamed of myself when I installed the IETab add-on for Firefox the other day and took a look at some blog postings. Initially, I'd installed IETab to try and sync up PicLens with a thumbnail folder view of an enormous image directory as presented as a windows explorer view. That didn't work, but I thought IETab was kind of interesting, so I duly went away and 'IETabbed' my bookmarks.

Oops. seems that that old align=right hspace=8 vspace=8 ain't what it used to be, and probably hasn't been since about 2003 or something. For blog templates written in HTML 4 (of which there are tons out there I've used or written), this old syntax is just fine, even if it's like the 'Hello World' of web design, but, you know, if it ain't broke. Except it is broke. In XHTML 1.0 (correct me if I'm wrong, but only in your head), those handy attributes are deprecated, so if your doctype declaration contains the XHTML 1.0 string (like this blog template), the page rendering is undefined. No problem, then, if you've been using Firefox since forever, because Firefox just understands that some people out there can't code for toffee and gracefully deprecates on your behalf. Internet Explorer, however, throws its toys right out of the pram. Because we always gave IE a hard time in the past for being rotten with supporting web standards, it gets all fussy if you make mistakes these days. At least, mistakes in the way IE wants to implement XHTML.

Suffice to say, align=right translates to something like align=centerwithnowrapanddoitrightnexttimeidiot. Meaning this whole blog has looked a right old mess on IE since I started. My fault really. I should have checked. How authoritative I must have appeared, spouting on about web design standards, customer experience journeys, usability and everything, when the very page I was writing looked like someone has thrown up a flickr photostream at random in between the passages of pompous rambling prose like this.

Anyway, you're probably reading this, if anyone is, through google reader or something, so it really doesn't matter. A new class in the CSS for those images fixed everything pretty quick. In case you're using FireFox, and you're now thinking "oh, I might just take a look at my blog to see what it looks like but I can't be bothered to start Internet Explorer which I can't anyway because I'm on Solaris and I don't happen to have a virtual version of XP running somewhere", then try IETab. It eats memory like children eat cakes at a birthday party, but its worth it.

AddThis Feed Button AddThis Social Bookmark Button

Technorati Tags:

Listening Post: Sleater-Kinney: The Fox

Wednesday Mar 12, 2008

Unified Web Feedback

If you really want to let us know what you think, there's any number of ways you can let us know, but these days, we should expect you to chose the web as your primary channel. In other words, we should support you pretty well on Sun's multiple web venues if you want to provide feedback on our products, services, or simply to let us know that the x4100 page has an apostrophe in the wrong place (which was probably something Iv'e done).

The truth is rather more sobering, as it is for many large-scale web sites. That's not to say we score badly. Its just that there is room for improvement. In the last year, there has been a team at Sun dedicated to resolving all our customer interaction issues, whether it be from first contact on a sales phone line, or a click on an email link, or even when you get your hands on a piece of Sun hardware and open the box. They're even looking at the box. One of the key components of that work is understanding the customer journey from first contact through to resolution. That might be manifest as a phone tree, or telesales lifecycle, or as a web feedback system.

One of our biggest tasks in understanding how to design a web infrastructure to support the wide range of web feedback we receive at Sun, is to map the customer journey from first contact, through task filtering and into an internal feedback system. Broadly speaking, this customer interaction can be categorized in three distinct phases; invitation, submission, confirmation. Within those phases, there are a number of related subtasks and subsystems that actually make the thing run (technical term there), but from a design perspective, we're really considering how to seamlessly manage the transition between phases and ensure a satisfactory conclusion for our customers. In addition, of course, the whole experience should be simple, consistent and concise.

Its a challenging task, and we're trying to accommodate multiple feedback types across multiple venues, and, naturally, tight project deadlines (which means I should probably be building wireframes instead of writing this). Where we're focusing our efforts right now is on just how far we can go with contextually-driven feedback. If we're able to categorize the invitation in terms of the customer task and the current context, we should, in theory, be able to cut a swathe through a task filtering navigation path and drive straight to the submission phase, where any options or forms are specific to the task. However, we can't be completely confident that our invitations will always be contextually clean. We'll often use a global navigation component to host a persistent link, and it wouldn't be enough to simply assume that because a customer clicked on a link labeled 'feedback' in a footer on a product page that they are necessarily wanting to provide feedback on that product. They might just want to tell us the site is very slow today. It may also be true that even though they may have accepted an invitation to feed back on a particular product, what they really want to say is that we've actually speelled the product incorructly, which we might call a 'typo', which as everyone knows, goes straight to the jitterbug queue labeled 'null'. Only joking.

Why is it unified web feedback? Well, feedback systems evolve, much like web sites evolve. In fact, feedback and venue, in a multi-venue operation such as we have at Sun, are inextricably linked, so we've nurtured distinctly different feedback systems on venues such as sun.com, developer.sun.com, java.sun.com and others. As we try to align operations across venues and increase efficiency for our customers, we're just trying to get to a place where we can synchronize activities more effectively. As far as design goes, unification, even though I''m cursorily referring to it here, is a sizeable problem, so I'm hoping nobody notices that I haven't cracked that nut yet.

AddThis Feed Button AddThis Social Bookmark Button

Technorati Tags:

Listening Post: Aphex Twin: Flaphead

About

The Sun Web Experience Design team is a group of user experience professionals committed to making the online experience with Sun the best it can be.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today