|Websites Take Teamwork|
code + content + graphics + ?
| 5:02 pm on May 8, 2002 (gmt 0)|
From another thread:
|When web production is compartmentalized into specialist professions, an imbalance often results. |
|If you have several specialists collaborating on the project, you either need someone to keep an eye on the overall picture, or need a team that understands that they need to work together to produce the website. |
The graphic designer, code developer and content writer have to understand a little bit about each other's jobs and be willing to listen and compromise. If someone in the web-team is a primadonna, the project will become lopsided rather quickly.
| 5:10 pm on May 8, 2002 (gmt 0)|
Even within me-myself-and-I this teamwork can be hard to achieve!
One project I work with has a development team of 6, and they coordinate the work of maybe 60 content producers at present. The biggest problems (and bottlenecks) we suffer seem to come from graphics design.
We can't put up a page without a template, and the design people often turn a deaf ear to the need for small file sizes. Their work is visually beautiful, but there's no way to execute it unless we go north of 100kb. I say it's like using oil paint on water color paper.
I've found that content writers are much more adaptable - just explain why a 400 word text block is not a good idea and they have little trouble with edits.
Are there ways that content providers are a pain in the butt to graphic designers? Coders problematic for copy writers?
(edited by: tedster at 5:17 pm (utc) on May 8, 2002)
| 5:10 pm on May 8, 2002 (gmt 0)|
With any implemtation that involves multiple components you must have complete unbroken communication. It involves great planning and lots of meetings. This requries that you have someone overseeing the project as well as overseers of each team if it is that large.
You must layout each step and how they relate so each team can set goals and deadlines. Each week you must have all the teams meet together to review their goals and give status on what was completed and what hasn't been, with a projected date of completion.
I recently posted a thread regarding working on teams and got your feedback. I work alone in regards to web design, but in my day job I was on a project implementing a multimillion dollar software suite. The project involved 3 companied working together with project members working on 5 different teams (each team had reps from each company). Testing, mock go-lives, and go-lives were all perfectly synchronized with all teams. Many team members flew in weekly, some were international from Australia. After viewing real team work on this 1.5 yr long project and how smooth it can work, I can't see any other way for any project, including large web projects.
| 5:10 pm on May 8, 2002 (gmt 0)|
Information Architecture and the World Wide Web by O'Reilly explains the dynamics of a web team very well. When you have designers, programmers, marketers, usability experts, and CEOs all having input on a project, you have a ton of different shades of perspective that can easily skew the project one way or another. In the end, the user suffers at the cost of corporate politics unless someone can keep a solid vision for the site throughout the project.
| 5:16 pm on May 8, 2002 (gmt 0)|
|Are there ways that content providers are a pain in the butt to graphic designers? |
As a content author, I can gleefully describe the one of the comments I've received back from our graphics designer.
Before designing a new template, she wants at least a mock-up of some text that will be relevant to what she's designing around. I've learned that vague handwaving about content, such as "You know, about 200 words, some bullets, a picture or too, and a couple of internal links" is just not enough. It's too abstract. :)
| 5:17 pm on May 8, 2002 (gmt 0)|
Ah, the cluster! Its taken me two years to mold my main designer into thinking SEO and usability when he develops Look and Feels for my clients. I play the role of project director and coding specialist, he does the graphics. I also have a third team member who handles programming, he has not been so easy to convert!
The goal would be to keep the number of team members to a minimum. The more people involved, the less streamlined the process becomes. The worst part is when there is a team from the clients end who is reviewing and making changes and they can't make up their mind.
I have a CD packed with Look and Feels that ended up in the archives because someone from the clients team didn't like it and they had the overall decision. Mind you, that 9 out of 10 others really liked it, but the decision maker is the bottom line!
Teamwork is essential in developing a successful web presence. Without it, nothing gets done. If it does, there is usually something not right about the end result because of the various attitudes involved in the process.
My feeling is that the SEO should probably be one of the project directors. The optimization of the site effects all of the team members right down to the person developing graphics for the site. If the client involves an SEO from the conceptual development of the site, then they have made a very smart move. If not, then rework is inevitable!
As an SEO working with a small team of people, I am adamant about being project director.
Graphics - You need to make sure those images are named properly, optimized to the nth degree and well planned.
Programmers - You need to make sure those URL's are spider friendly.
Coders - Its your responsibility to make sure the code is optimized to the nth degree. External files where applicable, CSS, minimal use of tables and cells along with proper directory and html structure.
Project Directors - You need to understand the team members responsibilities and make sure that all of you are working towards a common goal. In this instance, a site that loads quickly, is visually appealing and easy to navigate, ranks highly in the search engines and directories.
Oh, and lets not forget, it probably needs to generate revenue!
| 5:30 pm on May 8, 2002 (gmt 0)|
For small projects, the project director probably needs to take ownership of the SEO issue. They should be deeply involved in creating the SEO plan as well as explaining to each member of the team how SEO works (and their role in it).
Additionally, I'd put ownership of user-interface issues with the project manager. They neeed to look at the pieces as they come together and ask, very critically, does this work and does it flow?
To add to your list, content developers need to understand the whacky world of SEO copy-writing. I've done a lot of professional writing, and it took me about a month to recondition my head to writing comfortably with keywords in certain positions and percentages. I think it's easier to write a good press release than well-optimized
| 5:34 pm on May 8, 2002 (gmt 0)|
I have been a graphic designer for about 10 years. I have heard all of this before. The graphics people are so hard to get along with.
From my stand point programmers were always a nightmare for me. Content specialist and everyone else wanted a nice looking site, no problem. Programmers wanted things to be easy for them. I ended up learning how to code pages and would do all client side work. It made me learn how to plug in to the backend.
Now I pretty much have the same view of designers. The main problem designers have is they don't understand technical things. We just are not made that way. We have been taught that there are no strict rules. It took me learning programming languages to understand that there are rules.
The bottom line on all those graphics guys who are a pain to work with need to learn what everyone else is doing.
| 6:00 pm on May 8, 2002 (gmt 0)|
I am currently working on a real estate site. It requires gathering and updating mixed informations from 24 different house builders, 15 housing projects promoters and about 60 agents. Things can get mixed up quite fast without a good supervision tool.
The production team consists of
1 project manager
1 assistant project manager
1 still photographer
1 panoramic photographer
2 content writers
1 web graphic artist
1 HTML coder
1 PR guy/sales man
1 marketing guy (me)
I provided web site conception and a custom FileMaker management solution that takes care of almost everything. To some degree, every one in the team feels limited by overall specifications. Every one need to compromise for the other members of the team. They are "forced" to deliver acceptable formats before they can proceed to the next step.
Here is one example: each contact requires a fax number OR some email adress to be admissible. The program will go <beep!> and will not let you create a contact record if both of theses fields are empty.
Here is another: each house builder is required to give a general description of the house between 30 and 40 words. If it's one word longer or shorter than this <beep!> the content writer will have to edit it before he can fill another field.
They feel frustrated that a stupid and ugly computer program they never used before is telling them what to do. On the first days it was a real <beep!> symphony at the office! ;) I hope they will soon get used to it.
It took 2 months of planning and developpement before a single line of text was ever written for the site. I think it was worth it. Jumping too fast in such a project would have caused such a mess. It would have been just like most web sites.
| 6:05 pm on May 8, 2002 (gmt 0)|
How about the CEO? I agree that SEO input must be high up the tree, but the SEO must take his or her cue from the overall function the site is required to perform. In a very big operation, this might not involve the CEO, but it still might.
A few years ago I read about a move towards having a CIO (Chief Information Officer). I think the little dip in the market may have trashed that diection.
But somewhere along the line the C-level must direct the website. And, somehow or other, they must get an education too, or else they sabotage their own best interests.
| 6:28 pm on May 8, 2002 (gmt 0)|
>>>>A few years ago I read about a move towards having a CIO (Chief Information Officer).
I was speaking with someone the other day from a Fortune 500 company who was telling me to get in touch with their CIO, who pretty much oversees and has their hands in it all, so I guess the idea didn't get totally scrapped.
| 6:49 pm on May 8, 2002 (gmt 0)|
My software company( that I work for) has a cio who oversees all software development for the ceo. It is a senior vp position. The company is also a part of the fortune 500.
| 9:20 pm on May 8, 2002 (gmt 0)|
Following up with the CIO, I work for a Fortune 500 and we also have SR VP that is CIO. He has been axing jobs left and right. <crossing fingers>I have dodged his hacks do far </crossing fingers>
| 10:54 pm on May 8, 2002 (gmt 0)|
I'm a one-man-shop who tries to do everything. This gets around the communication problems, and I do only small sites.
My background is unusual, with a degree in fine art, but lots of technical, engineering consulting and some programming experience as well. And I love all of it.
Still I can tell you that this is not THE answer either (besides being unworkable for large projects). I doubt anyone can be really top notch at graphics and coding and content creation and networking and project management and SEO and also running a business. So some aspects probably suffer.
As far as large teams and schedule slippage goes, I always remember the old engineering manager's adage: "If an engineering project is slipping and you have to speed things up, remove a couple of engineers from the project."
| 11:11 pm on May 8, 2002 (gmt 0)|
Well, I don't run a fortune 500 company's website, but I do own a small website which is completely operated by volunteers. My team consist of department heads that takes care of their own section and we communicate on ICQ or via our TeamForum to keep up with what's happening. In my site, the Content people is the core of the organization, they are the ones that makes our visitor wants to come back for more knowledge. So when I talk to my team of department heads, I ask them "How can you makes it easier for your colleges who don't know jack about html to contribute to the site?" My view is that the easier you make it for them to do what they do best, the more likely they'll do it under a relaxed and positive postion. But then again, my team are volunteers, so they begin working on what they feel is what they like to do anyways :) At the end, it;s the performance of the content dudes that counts the most.
| 11:28 pm on May 8, 2002 (gmt 0)|
How do you coordinate volunteer content people who "take care of their own section"? Do they just decide what belongs, or do they have guidelines set by a higher authority?
I have a similar situation with one client (mostly volunteer staff), and the turf wars can get pretty rugged. We find content created for one section that undermines an important marketing decision for the whole site - so we veto it and get ruffled feathers, sometimes long term grudges, etc - all of which hurts the necessary teamwork even further.
| 11:58 pm on May 8, 2002 (gmt 0)|
Yep, you got it! They get to decide what belongs and what doesn't. However when they come across a major decision, they are adviced to bring the matter into the team forum where we discuss alternatives and the impact of the decision.
Tactic #1: Sometimes you have to let go of your own authority and trust that volunteer to let him do a good job. As part of a team developer, each of them has the right to advice on other's decision, especially the team leader which must respect each of his/her team mates. Respect means no matter what your volunteers do, they hold the final say at the end wheater to do it or not, you can only lobby them with good reasons but must never take matters out of their hands.
Tactic #2: Refering to the Turf concern, it is possible that the lack of communication may have caused this. I encourage my team to never use E-mail (because it is private) and instead use the team forum where everyone knows what everyone is doing.
Tactic #3: The team forum also provides a way of cultivication amoung the team. This means that every volunteer knows every volunteer by name and in turn, knows each other's daily live etc. When this kind of relationship forms within your team, it is less likely that a conflict arise that will heat up. Alienation is the #1 enemy within any team effort. One of our forum moderators and volunteer recruitment officer crossed each other one day accidentally, and because of the established relationship between the team, the two guys (in their 30's) were shaking hands digitally at the end :)
anyways, hope this helped!
P.S. Guidlines is good, but too much will damage creativity. That's why children are creative, they know no rules! LOL
| 3:44 am on May 9, 2002 (gmt 0)|
One, separate programmers from HTML guys, different task. Engineering software systems is not the same as building tables.
That being said, get the graphic designers out of the design side.
You should have a Usability expert design the interface. If you don't have a usability expert, become one. It's not that hard, work out some interface elements and draw them out.
This is NOT art, this is functional. I turned my mockups over the the graphics artist, and he and his assistant turned my ugly sketches and basic graphics into a beautiful site. When it launches, it's going to be awesome. But I CHOSE where each widget went for SEO and UI reasons, not artistic ones.
You should be able to design your templates in the same manner. You have figured out what the pages should look like, let the designer do the graphics.
Have the developers build whatever code they need to display the site. We do object oriented PHP with an object oriented style database implementation, but do whatever floats your boat. You can do straight Perl for all I care. XML+XSLT works if you don't want a to have a relational database, XML+XSLT gives you the power of the database, you just have to manually do the content. You still get easily changed template sites though.
Regarding the URLs, do it last. We use mod_rewrite to send everything to a parsing script. The parsing script analyzes the URL and figures what variables to set and what scripts to call.
Seriously though, get a process.
1. Architect the site
2. Design the user's experience
3. Beautify the user's experience (makes the clients happy too)
4. Make it easy for the robots to figure out
| 4:16 am on May 9, 2002 (gmt 0)|
My opinion - designers are not monsters :) Programmers are not monsters too :) Same with the copywriter.
They are all nice people... and hard to work with! BUT THAT IS PROJECT MANAGER's problem!!
He is the one to connect them all!! To make them work together..
And in my case, that also means SEO!
| 6:16 pm on May 10, 2002 (gmt 0)|
I've come to the conclusion that there is a heirarchy of importance to web development that matters a lot, and most development teams don't get it right. Here's my view:
1. Business purpose for the site; targeting
2. Information Architecture
5. Graphic design
Because layout and graphic design need to be determined before the other elements can be laid in, designers often end up with too much clout. Trust me, the exact color tone does NOT matter and that beautiful gradient may not affect ROI at all.
Because development teams are often in a rush, the targeting and IA steps often get short changed. This is a recipe for delay during development and disaster after the launch.
If the business purpose and IA are clear and precise, then the whole team has a much easier time and the final product really delivers.
Copy matters the most, but almost no one gets it. Sure, if you have lousy product photos, you're better off with none - but the copy is the most important part of the communitcation. Copy is why your visitors come - and why they convert.
| 6:37 pm on May 10, 2002 (gmt 0)|
>Trust me, the exact color tone does NOT matter and that beautiful gradient may not affect ROI at all.
- Sorry, tedster, I will not. :) Studying Phychology makes me think the other way.. I agree with the list of importance.. BUT!! I will insert "Usability" above Code/Copy/Design.. I would make "Usability" a folder with these 3 items in that! USABILITY IS ABOVE ALL and no copy can save the site..
The problem with the copywriters.. Most of them are skilled but.. came from Print world.. They are cool and professional..BUT KNOW NOTHING ABOUT search engines. They believe people love to read long copy and so on..
Problems with designers - they want that to look beatuful.. And always forget that is their own taste which tells them what is beautiful and what is not. Others might not think so ( and often they do)
Programmers.. Then know nothing about Usability at all :) Teach teach teach..
I would say,
Copy - 35%
Code - 35%
Design - 30%
Code+Copy+Design=100% = usability = profits and clients.
P.S. Design matters.. Branding, respect - design can help a lot.
Why people buy?? Even they do not know.. But the developers MUST know. Good designer = good pchycologist!
| 7:09 pm on May 10, 2002 (gmt 0)|
I agree with you about usability - it's an umbrella category! And a good bit of the usability input must come from testing, and not from team opinions!
That gives a different line-up
1. Targeting/Business Purpose
2. Information Architecture
-----a. copy [50%]
-----b. code [30%]
-----c. graphic design [20%]
As much as I'm a hound for valid, clean, economical code, I still feel copy is more important (and extremely underrated). I know I'm in the minority on this view, but I came to it through aggrivating experience.
Rough code still makes it into the search engines. Browsers still forgive it, in many cases. But there's no saving stupid copy - and that includes print-style copy on a web page.
Bare bones design with simplistic layouts can do very well - are Amazon's pages really all that gorgeous? But copy is the essence of a commercial site.
For now I guess I'll just have to keep that as my own secret weapon. I have recently restuctured one team in exactly this fashion, and the results are looking good. The general workflow we're following is this:
1. After the targeting and IA are set, the copy is created first
2. Then the designer reads the copy and creates the look
3. The coder puts the pages together, and often goes back to the designer with new requirements (NOT just suggestions)
4. And then we go back to the copy writer and edit for final tweaks
The challenge is that clients want to see a "look" early on. It can take some selling to convince them it's important to wait for their hit!
<added>The thing about searching for the perfect colors is that the web is not print - and even in print, the press can throw you many a curve ball. I recently dealt with a design that looked great on 24-bit CRT monitors. But on a 16 bit LCD screen, or any Macintosh, it was exceedingly ordinary, even dull!
Still, we're going ahead with it - because it just doesn't matter that much, IMO.</added>
| 7:15 pm on May 10, 2002 (gmt 0)|
<<But there's no saving stupid copy - and that includes print-style copy on a web page.>>
Tedster - have you been looking at my sites again?!
Seriously, switching from writing for print to writing for the web is always a difficult transition for me. I would welcome any secrets for good web writing!
| 7:42 pm on May 10, 2002 (gmt 0)|
Mardi_Gras, make your copy smaller :) I gave been "fighting" with the copywriter for some months just about the length.. He is addicted to A4 space:) MAKE SMALLER!
And do not forget about Search Engines...
tedster, I agree about experience.. That what gives us Unique Selling Point.. You have found your.. I still have been looking and assume that in some time might reach your opinion about copy.. But still think even colors are important. Why? I studied a lot in this field :) ( althoug I am not a professional designer..)
Believe me, that matters!! :)
Thanks for this brainstorm session!!
Makes brains work!!! :) LOL
| 8:23 pm on May 10, 2002 (gmt 0)|
Writing copy for the web - a grand topic, and worthy of its own thread. So I started one.