[thelist] process question: hi-end multimedia sites

Ray Hill lists at prydain.com
Thu Feb 8 03:33:31 CST 2001


> I have a tough time with job-hunting because I seem to
> fall somewhere in between the "programmer" and "designer"
> pigeonholes, plus I have some knowledge in other general
> areas (usability, accessibility, IA) but not enough to go
> around calling myself an expert & certainly not a specialist.

Wow.  I've found that being able to bridge the gap between the 
camps of "photoshop/flash-addicts" and "command-line-junkies" 
(no offense to either) has made me *more* valuable to 
companies.

Sounds like your recruiters just aren't looking in the right 
places.  In fact, we could use another person in my team at 
work.  You got a resume handy?  :)



> I'd be fine with the first recruiter if I'd buckle down
> & learn ASP, but I'd rather spend my time playing with
> front ends: graphic/UI/flash/javascript, leaving the
> databases to others.

Where I work, there's actually three departments.

The visual design folks spit out the pretty pictures 
(photoshop chop-ups) and flash, but don't really have any say 
in the functionality or flow of the product.  It sounds like 
your talents would be wasted there (unless you're really into 
designing logos and business card designs).

The application design team (where I work) takes the product 
specs (which we play a large part in producing) and creates the 
front end HTML to bring it to life.  This is where it sounds 
like you would fit in perfectly!  This is where having a 
combination of IA, usability design, HTML, and other skills is 
viewed as invaluable.

The engineering team, of course, concentrates on all he backend 
stuff.  They produce the server-side scripting that makes the 
thing funciton, but they've got about as much design sense as a 
rock, and the functional first-draft comes out very plain and 
ugly looking.  The design team takes the front-end HTML they've 
built, chops it up as needed, and works it into the server-side 
scripts that engineering churns out.

So even though engineering does all the dirty work on the back 
end, it's still *very* useful to have a solid grasp of server-
side scripting, both to make the original HTML design easy to 
break up into modular chinks, and to integrate it with 
engineering's back end code.

If you're just starting out with server-side stuff, I'd 
recommend looking at PHP instead of ASP.  PHP is a lot easier 
to learn, runs on more than just Windows (has a Windows and a 
Unix version), and the syntax will make it much easier to learn 
other languages in the future (ASP only makes it easier to 
learn Visual Basic - again, MS platform only).  Read just the 
first third of the book Professional PHP Programming andyou'll 
pretty much have it down (*very* well written book, I might 
add).

Professional PHP Programming
http://www.half.com/products/books/detail.cfm?item=292181


In our team, one gal concentrates mostly on application flow, 
two guy do mostly of the HTML/JavaScript and wireless stuff, I 
do most of the back-end engineering advocacy, and our boss 
keeps us all on track.  Since everyone's working together on 
the same project usually, being a bit less than an expert in 
one area of the process is fine, since the others can pick up 
the slack.  And you've got everybody's brain to pick when 
learning new stuff.  The important thing is that you know a 
usable design when you see one, and can contribute to improving 
the quality of the end product.  That *is* what makes the 
company money in the end, after all.  And QA is *much* less 
irritable when you hand them a product that the end user can 
easily digest.  :)


--ray





More information about the thelist mailing list