The Front End Guy is the Go To Guy – Human Interfaces

I do not know how many of you who work with front-end related tasks on a daily basis, but I sure do. One thing I have learned is that working with front-end related entities makes you connect to a lot of different departments within an organisation. Often this is a good thing, sometimes it is not as good.

A lot of different requirements must join forces in any tier within an architectural solution, but in the front-end, the closer we come to the end-user, more people belive they have a saying on any matter that may arise. This is very positive for the people who have dedicated their daily efforts into working with front-end development and other entities of the front-end (graphical design, interaction design, information architect, etc), because these people tend to get more insight into the product they are working for, because we all know that information is king, and with all these requirements from different departments, the front-end is the place to get to know and learn the core business. One not so good thing about being a human interface for user interfaces is that you sometime have no clear mandate and have to take on the role as a mediator, trying to tie the data-model-requirements together with the business requirements for time-to-market for promotional materials.

I stress that in larger organisations where there are a lot of people working with tasks and issues that effects the front-end, there should be some kind of position with a clear mandate making decisions when too many requirements from different departments start to mix and needs resolvment. This mandate could either be a person, with some kind of service architectural role, or a group of people combining different types of competences within the front-end area touching all involved stakeholders such as IT, marketing, operations etc etc.

Being the front end guy/girl is a good way to get insight into what is happening within the organisation, something that is sought after from a lot of people, but also a pretty quick way to headaches and frustration when you realise that you are sitting on all the information and no clear mandate to do the best out of it.

Some Web Development Links for You

Not a big update. 

John Resig is writing a new selector engine, sizzle, interesting

I wonder when John have the time to write code, write books, write documentation, write for his blog AND work for Mozilla. He is one productive client side coding entrepreneur. Sizzle is Work In Progress, but John claims it is 4 times faster than the jQuery Selector Engine.

YUI has a new Interaction Pattern in their library

I do not know how many times I have been part of discussions about how to implement a sign in procedure the best way. This new pattern from YUI tries to describe the characteristics of the problem. I really like Yahoo’s initiative with YUI trying to help designers and likes from revinventing the wheel time after time.

Parallax scrolling made easy with JavaScript

10 years ago something, we believed DHTML and JavaScript where the solution to everything, and there are solutions I am proud of from that time, and solutions I wouldnt mention even under torture. These days all client side stuff is focused on availability, usability and other non-relevant bilities ;-) . Where is all the cool stuff? jParallax is cool, and from a first point of view, somewhat useless, but hey, keep em coming.

Blueprint CSS 

I hate CSS. No I like separation of content, design and behaviour. But lets be honest, CSS is repetetive and often you find yourself chasing browser bugs hitting CTRL+S, ALT-TAB, CTRL-R, ALT-TAB …. That is why I believe we must minimize the rows of CSS we are actually writing, just as we try to do that with JavaScript using libraries such as jQuery, Prototype or Mootools. Blueprint CSS is interesting, I am thinking of implementing it into my mindset as the default CSS-library together with jQuery for JavaScript and Smarty for templating.

YAML (Yet Another Multicolumn Layout)

This one looks interesting as well, but the only reason I list this is because the name is the same as the configuration language YAML I will talk about below. 

YAML (YAML Ain’t Markup Language)

Before I have used XML for configuration, moving more and more over to JSON, because of the benefits parsing and using it. But YAML is what I have started using for some types of configuration, because of its easiness to read, write and share. Look into it. I love it for configuring navigations.