Killing Time

[andrewducker]

Putting off writing some code I've promised to write for my parents, fairly simple, but I can see that it's going to be making it nice to use that's the hard bit.

I _hate_ making things nice to use.  Once it's functional, the fun bit's over - I've made some part of the universe move in a way that does something that's useful.  I've bent it to my whim and shown that I was better than it was.  Making it look pretty is a job that's (a) never over and (b) incredibly fiddly.  I need to work with people that can deal with with aesthetics for me or they tend to just not happen.

Which is one of the reasons I'm _appalling_ at getting web pages done.  I know the basic syntax, but when you get right down to it it's all about _layout_, which is something I only care about up to a point.  That point being "It's readable."  I can happily debug other people's HTML code if I'm given a specific goal - "Can you make those tables line up" or "Why do the pictures keep moving about?" or something similar.  But faced with something that's just plain ugly I have _no idea_ what to do. 

It's not that I can't recognise the difference between prettiness and ugliness (well, ther's disagreement there, but I'm not going to argue about taste here), it's that I can't see a way from A to B - the fact that lightening the background colour, reducing the font size and dividing the layout into blocks will suddenly make it 300% more readable is just _beyond_ me.

For some reason this doesn't apply to text - I can copyedit until the cows come home.  I even find it fun.  I wonder if this is something I can learn, of if it's built in.

Comments

[chillies.livejournal.com]

Having worked in small software houses which have a large code base of scientific and engineering code built up over a number of years and where any specific programmers' code generally outlives that individual, I shall disagree.

Getting something functional is only the start of it, and tidying up code, setting good defaults and making the inputs robust, and doing the documentation are the things which make an application good to use and maintain. I've had to clean up the code of hot-shot coders who have been interested in getting a cool result in a new technology, or are working to incredibly tight deadlines. It's not nice and it's not easy, but it makes things easier for the next person.

Re:

[andrewducker]

Commenting and tidying are two things I'm very happy to do. Largely because I got fed up with not being able to read my own code two weeks later.

Documentation I suck at. Well, not suck, but I'm not great at. But documentation can be written by other people. It needs to match the code, but ideall it'd be written _first_, and indeed that's what happens at my current job.

Re:

[green-amber.livejournal.com]

Well, aesthetics is pretty much all I care about - teach me some HTML and Photoshop when Im back..

Re:

[chillies.livejournal.com]

Absolutely! When coding, there's a whole bunch of things one has to consider and trying to return to that mindset is hard. The obfuscated C contest is fun, but I'm not up to that kind of wizardry and think that the simpler the better. Succinct and well-documented code should be able to be read out loud (Geek Pride!) in much the same way that a mathematical formula is a continuous statement. If it sounds clunky and contorted, there's probably a better representation. And if it sounds good, it's easier to recall what the code does.

When you say the documentation is written first, do you mean end-user documentation or just the functional and technical specs?

Re:

[andrewducker]

end users?

I'm sorry, I'm not sure what that means.

(I'm involved in writing small chunks of a COBOL back end that will have a Java GUI written for it by people in a completely different department - presumably _they_ will write end-user documentation).

Re:

[bibliofile.livejournal.com]

I'm involved in writing small chunks of a COBOL back end that will have a Java GUI written for it by people in a completely different department...

Not to worry in this case, then -- the usability stuff (check out www.useit.com) is all about what the users will see.

In a perfect world, your company'll have tech writers to document the app for users.

[odheirre.livejournal.com]

It's funny. I went from a technical writer and web usability guy to a programmer. With programming, it's binary. Either it fulfills the test cases, or it doesn't. "Look nice" is so vague, and clients always bitch about "this doesn't look professional enough" or "could you spruce it up."

Both are fun things to do, IMHO.

[moniqueleigh]

I'm actually rather similar. I know what looks pretty (at least, what looks pretty to me), but have no clue how to get there. I also can't draw, but have what galoot calls an "artist's eye" - meaning I'm really good at seeing what doesn't work artistically (her arms are too long, human bodies don't twist that way, & such commentary).

All that is why I still don't have a website of my own. Well, that & I can't decide what I'd put on the darn thing.

[stillcarl.livejournal.com]

"Nice to use" and "pretty" aren't the same thing in my book. I class nice to use as almost as important as the code doing what it's supposed to do. If it's not nice to use the users will most likely make mistakes, or at least take longer to do something than they should. How it looks doesn't matter so much, but the feel's important.