Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Soon I will need to give a presentation on my honours project for the engineering faculty and a large group of engineering and technology students at my university. While all the the people attending will be technical-minded, not all of them will be programmers and most will be from other engineering disciplines.
I have given presentations before, and I am confident speaking to a crowd, but I realize now all the presentations I have given before have been to fellow CS/SE majors and teaching staff. I wonder if my presentation style assumes that I am presenting to other software geeks, so they will know what I am talking about and I can put on a more interactive demo involving the audience.
My honours project isn't terribly complex or theoretical, I have a prototype C# Winforms app but it is designed to be extensible and operate with different data sources (ODBC or WS) in the future, and some research to how it could be extended with a rule engine and DSL and turned into a marketable product. The organization that is testing my prototype is saving tens of thousands of dollars a year by automating a critical business function.
I had planned to show off how extensible it was by some live coding and UML-style diagrams. I really enjoy doing demos and live coding but I don't know if that kind of presentation will be as accessible to non-programmers, and I am worried if I get too geeky and technical I may alienate the audience and judges.
What are the effective techniques you have found to present software projects in a way that is also interesting to non-programmers
When I was working on my doctorate, the faculty gave us this rule for seminars - and it has proved very useful since:
Tell 'em what you're gonna tell 'em. (E.g., brief introductory problem
description and results abstract)
Tell 'em. (E.g. technical details comprising the bulk of the time)
Tell 'em what you told 'em. (E.g. brief summary and conclusions)
Open the floor for questions.
In your position, I would take about 10-20% of your allotted time to do #1 in a largely non-technical way. So you might describe the business function your code automates, why that's important, what things were like before and after applying your solution, how it's saving money, that kind of thing.
Then I'd launch into a highly technical discussion aimed at the CS/SE crowd. Even if the rest of the folks don't understand it and their eyes glaze over, your introduction at least will have given them a sense of what it's all about, and they might recognize a bit here or there.
For the third part, I'd briefly recap the problem and describe how you solved it in non-technical language, and then do your live-coding extensibility whiz-bang demo. Even if the non-CS/SE folks don't understand the demo, they'll see eye candy flying by and your professional peers and faculty all nodding and smiling, so they'll think it's cool.
I once attended a seminar by a guy who won the Nobel Prize for applying chaos theory to chemical systems. He applied this approach, so even though all the non-theoreticians like my fellow organic chemists and I were all completely out of our depth, the fact that the theoreticians were all excited left us feeling like it was a great seminar even though we didn't have a clue about what he'd said.
To appeal to both audiences, I sometimes give the technical explanation and then follow it up with my "in English, please" explanation. CSI and other dramas with science in them do this all the time, to good effect.
In other words, [insert plain english explanation here].
Lets attack this as a refactoring problem.
ie Instead of adding more to your presentation, Is there a way in which you can take stuff out?
For example I don't think showing off that your demo App can use multiple data sources is essential, much less grants for you to program right there during the presentation.
I know it took care in the design of your app to reach that point, but still most people are more interested in the OUTPUTS not the INPUTS of an app. And even more in the BENEFITS of said app.
Some guiding points:
Make the presentation about them. If the audience has felt the pain that your program solves, remind them of that pain. If they are other researches like yourself then ask them to put themselves in the shoes of the organization you helped.
Compare the old way vs the new way of doing things. Why is the new way more efficient? Will it lead to more sales? will it reduce inventory? or save money? Will someone lose his/her job because your solution makes his task irrelevant. Note: When making technological presentations I've observed is important to address what happens to the people that was doing the task previously. Fortunately most of the time people don't lose their jobs, in most cases the same people can manage a much larger volume of work thanks to
Technology.
Show results. What are the real results your demo company has observed?
Use meaningful visuals. If you could make some animations that explain your algorithm even better.
Tell your point at the beginning and the end. Most people will forget what happened in the middle so make sure to tell the most important thing at the beginning and the of your talk.
Practice, Practice. Yeah it sounds ridiculous but do your whole presentation in front of a mirror or video recorded at least twice. The more the better.
Don't give one of the most important presentations of your life without a rehearsal.
Breath and be positive you will do fine :-D
PS: My suggestions are derived from this webpage. It has guided me several times:
6 Stimuli to reach the old brain
You're already working on knowing your audience, which I think is awesome, you just need to take it a step further, and ask yourself, if I were x person in the audience, what would I get out of this presentation.
I'd question the validity and how much effort should go into the technical/coding demo, if the group you're presenting to is never likely to use your specific implementation. It may be more important to portray how you approached the extensibility, so that you garner ideas within the peers on how they can approach it in the future, as well as hit on points throughout that are important to all of your audience members, and maybe shortcut the demo a bit to just show that, yes, indeed it does work.
I don't know about you, but personally I've always got more value out of these types of presentations based around how the project appeals to everyone, how you are managing to save tens of thousands of dollars per year for this company, theoretically why other companies might want to use it as well, what is the market and other factors, what were the giant technological hurtles you had to overcome, even if it's a simple project, there were things you must have thought about ahead of time to avoid and prevent you from getting backed into a corner.
I think if you're a really good presenter, and the purpose of the presentation is to be broad and appealing to the entire group, and not a talk on the chaos theory and application to chemical systems, which has that stated purpose, you should appeal to the lowest common denominator of the audience, and the entire audience can be entertained and appreciate what you have achieved at every step along the way, and to do this, they don't necessarily have to understand every step taken either.
I've been in the same situation
(presenting a software engineering/image processing/recognition project in an EE faculty competition).
Start with the issue (the problem)
Then the background (a BIT of technical background)
The solution:
Start with block-charts (all engineers read those)
Then explain the technologies and how briefly - how complicated the implementation was
(don't underestimate the complicated part - otherwise you may make your work seem to simple to engineers from other fields - they won't appreciate your effort)
Results:
Show short visual examples (try to make them intriguing)
(short code examples can go here)
Short user interface demo
Show impressive graphs
Bibliography, thanks, possible future improvements/research
Questions (if the forum is large, tell them in advance that the time for questions will be at the end)
General advice:
Practice presenting (over and over)
Leave 45-60 seconds per slide
No more than 5 points per slide
1 line per point
Add jokes
No animations except for demonstrating complicated issues faster
Use clear fonts (Ariel or Calibri for regular text, 1 different font for titles)
Use high contrast colors
(bright on black or dark on white if you must - no dark on dark or bright or bright)
Well first of all, I would suggest talking to your faculty advisers about what they expect from your presentation. If there's any question about how you should balance technical details understandable to only CS people versus more general concepts understandable to the larger audience, I think it would really help to get input from those who will be evaluating you.
One thing I really like to see from a presentation is a "take home message". What is the one thing you want everyone in that audience to remember long after they've left the room? Tell them the take-home message at the very beginning. Tell them you will spend the rest of the presentation explaining why they should care and why they should believe you. Even if people get lost in some of the technicalities, if you at least drive home that one message, you've delivered one thing to a lot of people.
Another suggestion: don't forget about format. Presentation slides should be readable from anywhere in the auditorium/lecture hall. Don't overwhelm people with too much text on one slide. Keep bullets short and easy to scan. Do you want people spend their time reading your slides or do you want them to listen to what you have to say? Don't use acronyms, but if you must, explain what they mean--and put the definitions on your slides--unless you are sure they are common knowledge. If people are sitting there wondering what the heck that acronym means, they aren't listening.
As to whether you should show actual code or do live coding, my gut feeling is that you shouldn't unless it's absolutely critical to the point you're making. If your project were actually about some coding construct (e.g., if you had invented the concept of an "extension method"), okay, it would make sense to get into some actual code. But it sounds like the significance of what you've done is definitely up a level from that. You might want to show how little code it takes to, say, hook up a different data source, but I wouldn't actually get into walking through the code itself unless you feel you can't make your point otherwise. One thing I probably would like to see if I were in the audience is a demo of your code in action. Show me what is does, and tell me why that's cool.
I hope it goes well!
Here is my advice:
Be clear who your audience is and what your message is - Are you trying to impress six faculty members who are marking your project, or proving you can entertain the whole audience.
Have a Contents page early on - that way the audience know what to expect.
Put the geek stuff in an appendix to your main presentation. That way you can dip into it ,for questions, but you will not loose the main point of your talk.
Make sure your presentation flows and tells a story - limit slide numbers and don't clutter them e.g. project goals,possible uses, design challenges, software choice, what you did (limit techie), results (demo), results and limitations, next steps, questions.
Have a Conclusions page at the end -- make sure you circle back and cross refer to your original contents page.
Leave 15-20% of your time for questions. This will reveal what the audience is interested in, and allow you to display a deeper understanding of the topic i.e. only do live coding if they ask for it.
Rehearse out loud even if you feel stupid doing it.
Good luck.
A few tips
Use a common technical language. only use terms that the hearing will recognize.
It links what you expose yourself, with examples recognizable by the audience.
you can also read these great articles.
11 Top Tips for a Successful Technical Presentation
Tips for a Successful Technical Presentation
Bye.
Mix and match some topic everybody know. It has helped me to theme slides with images ranging from the Divine Comedy to the Simpsons I don't know how formal is your presentation but it's a common constructivist technique to hook on something your audiente already know to show your point.
I once attended a presentation of Larry Wall where he explained Perl 6 features using examples from golf mixed with the Lord of the Ring.
What I do is to talk analogies, try to convert to real world the terms you are explaining.
BTW, Why are you talking about software tech aspects to non tech people?? You have to target the content to your audience first. Who is your main audience?? The techies or non techies, choose one.
Regards,
I'd be inclined to not use code (unless you actually have to), and use some form of generic (and straightforward) pseudocode.
Also, if you are doing the talk with prompt cards, put 'Breathe!' at the top of the cards. It helped me...
Focus on the user interface (aka how it makes their lives easier) and how it is different from similar products (why they should listen.)
I think Simon Peyton Jones gives excellent talks. See the How to give a good research talk section on this page. In particular, check out the video of his talk about the subject linked to in that section. You can find other videos out there of his talks on Haskell, functional programming, etc. to see how he practices what he preaches.
Please listen to the following podcast : Manager Tools - Presentation basic
It will cover all the basics you need to do effective presentations.
Now when doing project presentations do the following:
Create a High Level Architecture model ... see this model you can probably do better (note: the model image is from my blog.).
Create a High level requirement list
Create a application workflow process diagram (once again pretty colors, arrows and blocks). This model will show how a user is expected to work with the application in order to solve its main task.
In order the present the application first show them the requirement list and talk about them, then the high level architecture and finally the application workflow process diagram which can be followed by a live demo.
The most important rule is to present at a fairly high level with lots of diagrams and models to show what you are talking about.
Related
how would you handle a client who wants you to implement a website layout that looks horrible and is wrong in many many ways, when they absolutely think it is great, really "different" and cool and since you are a programmer, you don't know anything about design.
i have tried arguing, reasoning and not caring, but it pains me physically to think that i should put that online... any tips or experiences would be great! thanks.
update: things are even a bit more complicated, since it is not just any client but a business partner with a great business idea, that i want to be part of...
Craigslist.com is one of the most visited websites on the planet. Yet its UI is appalling by most modern aesthetics.
This isn't a technical issue, but a business issue. You need to sit down with your business partner and put forward your point of view convincingly. If you're going to work with her in the long term, then you both need to find a way of resolving issues and coming to a compromise. Look at this dispute as a warning sign about the business relationship.
I've some experience with what you describe. I usually try to convince them their design is not as good as they think. Things like usability, navigational structure can help you in the argument. I've noticed that showing some heatmaps of how people look at websites can have a nice result. "I never looked at it that way"
If they however insist on the bad design, you have roughly 3 options:
Politely tell them to find somebody else to create the ugly site for them.
Make them sign a document that states that you strongly advised against the design and that they cannot hold you responsible if they get bad results or comments
Bow your head and build it.
Option 1 can hurt your reputation just as bad as option 3.
Option 2 sometimes convinces the client that they might be wrong after all as it is now written on an official looking piece of paper they have to sign. But a least ensures you can work with a clear conscience; you warned them, they wanted it anyway.
Good luck :)
He who pays the piper calls the tune.
Depends how much the coin matters.
Managing difficult clients is something you need to come to terms with, as a freelancer, or any sort of sufficiently experience professional.
If you don't like the design, you can have a simple thought: Do I need this client? If not, drop them. If you do, then just accept that you don't always get things your way, and deal with it.
If you don't want your name attached to the work, you can easily come to that compromise.
Sometimes you need to make moral choices about clients as well; in this case you just have a subjective art choice; I think it is easy enough :)
I have had some cases as you describe. Just keep in mind that you are creating something for your client, it's the client that will work everyday with the application and it's the client that need to be happy with it, not you :)
There have been a lot of answers that boil down to:
Just do it for the $$$
Do a mock up of something better
Run a usability test
Run like hell (but politely)
All of these assume that:
The design really is bad
You are objectivly approaching this project
Please don't hear what I'm not saying: I am not saying your premise is wrong.
First, I am saying its worth considering that it may not be that bad. There are a lot of very successful sites out there that drive designers nuts. If it doesn't satisfy a need, it won't matter how well its done.
If you want to be a part of this than you need to look at the business plan first, and see if its valid, and if the site will fulfill it. If either one of those is a no-go, than fix those problems first.
Second, ask your associate if (s)he's considered other designs. Ask for the sites they used to come up with what they want, and ask what else they've considered.
If they give you something, look at what makes those good/bad and see if between the two of you you can come to a better design.
If they can't, then tell them that with some work there may be something better and work together to create 3 or 4 mock ups. Then whip out the usabilty test. Even if you've done them before, I highly recommend reading what Jakob Nielsen has to say about it over at http://www.useit.com/alertbox/
Since this seems to be a business partner, just doing it for the money and/or running like hell doesn't seem to be an option. Working through this with a little more give and take may help, but if you can't come to an agreement, then you probably ought to leave.
Ask users that match targeted audience
Why don't you create a mockup of a particular part of this app/site and try asking a few people that represent the persona of the product. The targeted audience. Give them two possible choices and let users decide what will make business value instead of you or the client.
Be careful since the first thing I would do when coming to such a website is to look who's the webmaster that produced that site. And then if I would see your logo below it wouldn't impress me. It's not for your good reputation.
So as a professional in that area, I would try to discuss the design with your client, offering him your knowledge about good website design, since that may be also part of the service you're offering.
If you really need the money, just do what he wants and take the cash. Avoid your name appearing on the site anywhere.
If you have other work lined up, tell the client you think he would be better off with a different designer that can meet his needs and say goodbye.
My experience of this kind of client tells me they are a royal pain the arse, with endless tweaks and adjustments to the design. Get out while you can.
Do it. In your own time do your own version - as you want it to be great, which you do as you have a stake in it (you want to be part of it). Show them the better idea. Make them buy into it by making them feel part of it, not that you have done it behind thier back. the idea just came to me and I done it. If they don't like it tough – you could never have won. However they might just be impressed at your effort and/or initiative.
I'd say do it but put nothing identifying you or your company on it, and keep it the hell away from your portfolio. Also have very explicit conditions around ongoing support for it.
Maybe you could bring in a third party, someone whose opinion on design and suggestions for improvement your business partner would respect -- maybe a graphic designer or a web usability expert. That way, you might be able to salvage this business opportunity without alienating your business partner.
I agree with others. If you don't need the work than politely decline. If you do, release what the client wants and make them pay for every tweak after launch once they realise the design sucks.
Perform usability tests. Create a mockup that's fairly close and get people involved from the target audience. If they are a designer then they should understand that this is a sensible approach. Be careful to introduce it as best in both your interests.
The key is to get independent feedback. That keeps you sweet with your business partner and you also get a good design.
If it's a bad design and it's being pushed, then it's someone's "baby" and you can't touch it.
It won't matter how good your alternative is. It won't matter if you can point to the exact same site in, "Web Pages that Suck." It won't matter if senior executives quietly say, "Wow - I really like the alternative - it makes us look Fortune 500!" It won't matter if you bring surveys, focus groups, or if Jesus, Himself, shines the light of truth on your alternative and blesses it: you'll be branded as a, "non-team player," and the cruddy site will STILL be posted.
Then, in 18 months, after you're gone and the three people who were hired to replace you EVENTUALLY cough up a site with minor, almost embarrassing, changes that actually make the site resemble an ad for adult incontinence products, you can come back to this post and say, "Hey - thanks. You... were right."
I want to add an Link to my question:
Storing Password in Databases in plain text vs Customer Needs
In some cases it is the same issue. There are customer needs that are not acceptable. the answer provided in that question maybe help you find a way around that problem.
I think I've worked with this person before, when a university website was being designed by committee. We had two people come up with designs, and the initial vote went 12 to 1 ... the one who was ahead was done by a professor of commercial art, who couldn't care less if you didn't like his design. The other one, though ... she had to come out and defend every little aspect of her design. The revote was 1 to 12, as I refused to change my vote.
Luckily, three of the people from the graphics department came up with a new design, and presented it at the next meeting, and everyone agreed it was better, so we were able to torpedo the blinking splash screen and George Washington's hair design.
Anyway, the point is -- you have to find out why she prefers her design, and then come up with something that takes each of those points, but doesn't suck. Unfortunately, it might take someone with design experience to manage to put it all together -- but if you're planning this to be a business venture, it might be worth spending some money on.
Here's my suggestions:
Why is the design bad? Make sure you understand why before you get into this conversation. Remember, there is some business goal behind having a website. Understand that, and use it as your point. If you don't know what the goal is, ask. If they don't know what the goal is, help them figure it out.
Offer alternatives. Point out the positives and negatives, and help them understand what the tradeoffs are.
Mockups and tests. If you can, mock up the alternative, and let them see the differences. Get potential users to try them out if possible. If not, at least have the customer use the mocked-up website as an actual customer, trying to fulfill an actual scenario.
Good design is the design that will meet the stated business goals of the customer (assuming that this is a business website).
Also, understand what your job is. Is your job to help them solve a business problem, or to implement a specific solution they have in mind? Understanding their expectations of you may help significantly.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm looking for advice on how to give a junior developer a chance to gain experience on a big project with tight deadlines without hurting the timeline. If we all know it will take a little longer with the developer because of less experience, then what is the best way to give them a portion of the project and spread the risk? Giving these developers the ability to learn on the job on real projects instead of handing down maintenance work all the time is important to me, and I want to find a way to make it work.
You need to know if they grasp the problem you are handing down. When I have to do this here is my approach:
Give them a piece I think is a stretch for them but doable.
Explain the importance of the piece, how it fits into the larger picture, and how they will contribute to the project success.
Ask them to go away, take some time to think about it and then write up several possible solutions with pros and cons of each. This shows me if they have grasped the problem and if they can design a solution.
If they come up with something that looks reasonable, then let them at it. If not, we meet and discuss the problem some more and I give them another shot.
Giving them a chance to design the solution gives them ownership and lets them prove themselves. Having them communicate the design to you first with pros and cons gives you the confidence that they can complete the solution on time.
If they can not think of any possible solutions and possible outcomes of each solution then they are not ready to step up to this problem. They will need closer mentoring and smaller problems which have been designed by another more skilled developer first.
Very short, clear goals that are measured and checked on very often.
Bite size approach will help the junior realize that big things are accomplished by doing the very small things, very well, over and over and over...
Also, consider doing the conceptual design, or a feature spec, or even the tech spec to get their feet wet and let them have more and more say if they take to it like fish to water.
Although this wont work in all shops, pair programming is a great way to get juniors on board quick. However pair them with some of your more sociable developers for best results.
This way they get mentored, are doing important work, and learning important things related to your work-style, and the more sociable devs in your shop will probably enjoy mentoring juniors anyways.
How well do you know the junior? Certainly there must be something he/she has shown an interest or special aptitude in. Try finding pieces of the project that are digestible and fit the profile.
Assigning a mentor and making sure design and code reviews are a part of the process are important, especially if the junior is not well known.
If the junior is new to the subject matter, technology, or team, it may be advantageous to also make sure the piece he/she gets to work on is one of the better documented pieces (decent requirements definition, and possibly even a tech design already prepared by a senior). I have been able to do this in the past. I had a reasonably well fleshed out technical design of a medium-sized task, parceled out parts of it to a new team member, then also did code reviews and corrected the work. Even with the time spent doing the review and correction, it was a great way to get the new dev involved and use their ability to help finish the tasks. The new dev learned a lot along the way too.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For instance, customers that we're creating web sites for, request things like:
all links should open in a new window
put custom 'Back' button on every
page while there is a working
browser's equivalent
make some part of the text blinking etc.
Of course I tell them it's wrong, but is there some nice list of bad things to have from a respected source that I can point them to?
Become that respected source. Seriously: if your clients are showing reluctance to take your advice directly, compose documents that illustrate good and bad user interface design and publish it on your website. You gain three things from this:
You become more knowledgeable about the why of bad and good design. Having to think through something to compose it into a document is more helpful than many give it credit for.
If this is publicly published, you probably will get feedback about your ideas. Throw away the bad suggestions and integrate the good, and you become better at your craft.
You have the source for these discussions in a presentable format, yet you retain all your personal branding. If you include examples and demos of the good and bad, most people can see why you advocate for your ideas.
EDIT: epotter is dead on as far as the "buck stops here" aspect of interacting with a client. If your documents can show why irritating a user is a loss of revenue in the long run, it is unlikely you will have much push-back. On the other hand, if your personal preferences includes UI designs that don't help with retention... stop doing that. (I recall the days of "CSS Only, No Tables" designers before CSS had matured: they insisted on forcing their designs on clients, even though in some browsers they didn't render well. While a cause is admirable, you work for the client not a cause.)
Always try and show them how it will cost them money. For example, if they are going to do something that annoys the user, they will have less traffic which will lead to less revenue.
For better or worse, dollars always speak the loudest.
First, don't tell them it's wrong.
They may take it personally.
Instead, understand the need they are trying to fill, then suggest alternatives that don't include the bad behavior. Mock all the alternatives up and point out the good and bad of each one. Let them choose. As long as you have a good alternative, and sufficiently pointed out the faults of the bad implementation, then they generally come around to your point of view.
In other words, act like a designer. When a customer says, "I want green text on a red background," you don't immediately tell them that 10% of the world's males cannot read that, you first need to understand why. "Well, it's Christmas," then you can suggest alternate themes to give the site a festive feel without the design error. As long as the mockups you suggest are better than theirs then they will generally acquiesce.
Not because they made an error, but because you saw their real need and improved on their idea.
If they're adamant after that, though, do the work - don't spend your time trying to convince them the error of their design sense, it's a waste of resources.
Educate them over the long term, but if it takes you an hour to convince them not to make a change, that's one hour you could have spent improving your relationship with customers who treat you as designers rather than web-monkeys.
-Adam
I've had to play a semi-sales role at time with web projects and I have to stress how important it is to keep the customer happy.
Nevertheless, I completely agree with you that you are obligated to say something in the name of giving them what they want. I always found that the best approach is to start by agreeing with them (in principal at least). You could say,
"I completely agree with you that this
text is very important to your users.
Many testers that I've worked with
have strongly preferred using this
font/graphic/color to call out
critical text. Unfortunately, some
users associate flashing text with ads
and avoid it"
I find that this approach lets them know that you
Understand what they want
Appreciate their motivations and suggestions
Only want to help
One last word of advice, if after the gentle nudging, they don't get the point, consider doing two quick mock-ups. (their idea and yours). If that doesn't work, then just give them what they want. In the end, they pays the bills and if they really want an ugly site (assuming you can't afford to turn away business on aesthetic grounds) just give them the site.
Good luck and take deep breaths!
Jakob Nielsen's Alertbox has been an invaluable source of common-sense usability advice for me for many years. Here's something he wrote way back in 1996 that still applies today:
The BACK feature is an absolutely
essential safety net that gives users
the confidence to navigate freely in
the knowledge that they can always get
back to firm ground. We have known
from some of the earliest studies of
user navigation behaviorthat BACK is
the second-most used navigation
feature in Web browsers (after the
simple "click on a link to follow it"
action). Thus, breaking the BACK
button is no less than a usability
catastrophe.
And here are the first two of his Top Ten Web Design Mistakes of 1999:
Breaking or Slowing Down the Back Button
The Back button is the lifeline
of the Web user and the second-most
used navigation feature (after
following hypertext links). Users
happily know that they can try
anything on the Web and always be
saved by a click or two on Back to
return them to familiar territory.
Except, of course, for those sites
that break Back by committing one of
these design sins:
opening a new browser window (see mistake #2)
using an immediate redirect: every time the user clicks Back, the
browser returns to a page that bounces the user forward to the undesired location
prevents caching such that the Back navigation requires a fresh trip
to the server; all hypertext navigation should be sub-second and
this goes double for backtracking
Opening New Browser Windows
Opening up new browser windows is like a
vacuum cleaner sales person who starts
a visit by emptying an ash tray on the
customer's carpet. Don't pollute my
screen with any more windows, thanks
(particularly since current operating
systems have miserable window
management). If I want a new window, I
will open it myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
These aren't crazy newfangled ideas, they're decade-old guidelines based on hard research. You'd need a really, really, really good excuse to repeat a decade-old mistake.
Find examples of actual pages that do this and show them. Here's a good place to find some.
If you show them the examples, and instead of being awed by the suckyness and changing their minds, the clients say, "Yeah! That's exactly what I want!", then make them sign a nondisclosure contract saying they'll never tell anyone who designed their web site. :)
You have to explain "why". It's not enough to tell them something is "wrong" (and in these cases, it's not so much "wrong" as it is a "bad idea")
Most people respond well to logic and reason. If you can make a reasoned argument for why doing something a certain way is a bad idea, they'll usually bow down to your experience and knowledge.
useit.com is an excellent resource for usability arguments
but you're probably wasting your time. Either do it their way ("the customer is always right") or walk away - arguing is unlikely to improve the situation unless you can demonstrate a significant monetary gain from not doing it their way, which you probably cannot do given the issues you listed.
if your name will be on the site, i'd politely walk away
Show them some articles on sites like http://useit.com which has some empirical studies on how adherence to web standard practices increases usability and so therefore user satisfaction and so therefore profit.
Ask them what results they're after. "Have all links open in a new window" is a statement of solution. Solutions are your job, the client's job is to state objectives.
Start with this: "Oh, you'd like links to open in a new window. Tell me more about why you want that - I'd like to explore with you whether there are alternate ways of getting the same results."
Perhaps continue with this: "Also, I might point your attention to other consequences of opening all links in a new window - consequences you might not have considered, and which perhaps you wouldn't like."
Suggested reading: Dale Emery's articles on resistance.
At the simplest, try to explain them each of it in a user understandable manner.
e.g. Blinking text is an old style thing not supported by all browsers
Not sure why "back" can be a problem. But put your viewpoint.
It's always convincing if you demonstrate to the user that his design is unconventional or wrong by showing a list of very well known websites that he would "respect" and pointing out how they don't do X. Your customer will probably want his site to be like the big players' web sites.
If he still insists that his weird design makes sense you could say: "yes, I agree that sounds like a good idea in theory, but the fact is that users are simply unaccustomed to X and would walk away from your website if it diverges too widely from the standard way of doing things".
IOW, when all else fails, use fear.
You can lead a horse to water, but you can't make it drink.
With customers (of any type), the best you can do is inform them of their choices, and why they are not the best ones and then leave it. If it's really bad, require sign-off stating that they find that design acceptable. Do you want to be 'right' or do you want to get something into the customer's hands that works?
If it completely impedes a working solution, then (and only then) should you stand on principle, but beware you have very few (if any) of these 'stands', so use them wisely. Be prepared to walk away.
Paul.
Unless there is a compelling business case NOT to do it (and I'm not sure this is the case with any of your examples) then if the customer is adamant DO IT! They are paying for it after all. They can always find someone else who will do it if you won't!
I am working in the web dept of a large legal firm, and among other things am responsible for maintaining a professional look for all our email communications (over 600 pieces per year).
Right now I am in a rut. Using a lot of pressure and manipulation, a person in management got to "art direct" a couple of HTML emails working directly with a member of my team and I caught the design at the last moment.
Her "designs" introduced background images behind the text of the emails along with additional, high-contrast imagery sitting behind the title in the header.
I ended up mandating a design change, however she is very insistent on "her" design and questioning all my reasoning for simplifying the look.
Basically she is questioning my expertise and asking for "proof" that her design is not user friendly.
I have the meeting in a couple of hours and was wondering if anyone here could point me to resources that discuss these specific items:
Argument against background images positioned behind the copy of an email. The images are at about 10% opacity, which makes them incomprehensible, and makes the design busy and ugly (my perspective).
Argument against high-contrast images behind titles.
Now, I am aware of the technical implications of including images in HTML emails, Outlook 2007 not loading background images etc. This is not necessary a technical issue, but a serious aesthetic/usability step in the wrong direction.
Thank you!
Facts:
Common sense in communicating dictates that anything that distracts you away from the message -- the content of the emails is not a good idea.
Is there images in the background of your letter heads and on all your invoices? Why so? Why not?
What do background images contribute to the value and perception of the message, the image of your corporation? Is it clearly known the impacts they have?
Go take a look at email newsletter sites. They are covered in guides and tutorials on how to email market effectively.
www.icontact.com
www.constantcontact.com
and so on..
Opinions:
Emails are not meant to be flyers. They are meant to communicate, clearly, simply and concisely while bringing a professional image. Making it look like a cartoon, or a flower shop, or whatever else you are dealing with probably doesn't add to it.
The issue you may run into is she is taking it personally because she is attached to the design for personal reasons and not designing for the needs of the business. So an attack on the design is an attack on her. She is too involved with her ego of looking good and avoiding looking bad or wanting some kind of glory.
Simply put, she should be the one qualifying to you why it IS good design, not the other way around. If she doesn't know, why is she asking you to prove it to her? How would she understand?
There's a book called Dealing with difficult people that may be of use to you.
Of course, if common sense was really common we wouldn't have to point it out as being common sense.
Update us on what happens!
http://www.asciiribbon.org/.
They have a lot of points on why not to use HTML ect, in emails.
Quite a few e-mail clients do not support HTML e-mail.
Other clients have a very poor or broken HTML rendering, causing the messages to be unreadable as well.
Sending HTML e-mails causes great overhead, and is very inefficient.
People that are limited to a text-only terminal, people with disabilities, blind people, basically anyone that cannot use a graphical interface easily or at all, are likely unable to read your mail.
(Extract from link)
In addition to what others have said, consider legal accessibility requirements. I found one example of the US Department of Education accessibility requirements. I'm sure searching for this one can find more examples.
Although it doesn't really apply, you may be able to reference the Americans With Disabilities Act, assuming you're in America.
Also, since you're sending HTTP formatted mail, maybe the Web Content Accessibility Guidelines 1.0 are of interest. For example, Guideline 2.2 of this document states "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen."
A professional email should only be graphic-intensive if those graphics either emulate the look of the company stationary, emulates the look of the company site, or if the graphics are interactive. A common example where this makes reasonable sense would be billing emails from Amazon.com. Note, however, that the content itself does not actually have any graphics, only the frame above, below, and to the sides of the content uses graphics. Similar stuff shows up in banking emails and paypal emails. This sort of thing makes it easier for people to associate the email with the site and makes for nicer printed records that match the online version of the same records.
For standard communication, I'd just go with a header and/or footer graphic.
What I did was escalate to a person who has both the position and understanding of the importance of the issue. Also, presented a version with a cleaner design. Made sure to address all objectives, and did not imply that design decisions are open to discussion.
I HATE email with designs and pictures on it. It is unprofessional IMO
I hate them.
the desirability/niceness of designs and art are subjective. So, how can you be sure all the people who receive them will appreciate them.
For me they are a big turnoff.
Also consider looking up some references in Human Factors engineering texts that show readibility studies. I bet a quick library search in this area would yield much scientific data that her way causing reading errors, eye strain and or slower reading speed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a development process question.
Background: I work for a modest sized website where, historically, the designers created mockups/screenshots of what they wanted pages and components to look like, and the engineering team (myself included) turned them into html/css.
This works relatively well from a code cleanliness perspective, and helps significantly when it comes to writing javascript. It has fails, however, in helping to maintain consistency from one page/component to another. On one page, a header font might be 12px and on another 11px, largely because its a complicated site with lots to keep track of (and we've cycled through 4 designers.) We have only a few truly universal styles, and they only get used when the engineers recognizes the style - not when the designer tells them to.
Our most recent designer is a relatively capable HTML/CSS coder. We thought we might have him create mockups in HTML/CSS and hand us off the code for quick integration. Our hope was that the designer would be better at being consistent in his style and that it might save us some development time up front.
What we've discovered is that our designer is not quite as good as CSS as we had hoped and that his code is often slightly bloated and incompatible with what we need to do. Also, his style of coding is fundamentally different from the rest of the engineering team and isn't jiving terribly well with our established coding practices.
Question: How do you do the hand off from design to engineering? I know I've heard of companies that let their design team do all of the template coding, but I'm curious how that works. Does the design team actually incorporate members of the engineering team in those scenarios?
As we're structured right now, there's not a chance in hell we'd let our designer write the final templates and check them into SVN, even if he was a proficient HTML wiz. There's too much in the templates that requires knowledge of our codebase and of potential performance issues.
How do we get this process working? Is it a pipe dream?
Specifically - personally - since I come from a web-dev, small-shop background I do the CSS work and slicing the PSD (typically) myself. But then I like to think I'm well rounded like that :)
Generally, the best experience I've had of this was a largish company with very defined groups of developers including the design team who produced the gfx, the apps team who did the vast bulk of server-side coding and app architecture, and the UE (user experience) team who sewed the two together, producing XSLT/JSP/HTML markup in general, and the CSS and JS for the client-side.
There was a very structured process of:
userstory ->
"wireframe" (documents) ->
design (PSD) ->
"flat" markup (DHTML only) ->
integrated markup (with web-app)
Where "wireframe" would be close to a spec for UE, produced with UML or maybe visio. I have heard the term applied to step 4 which I think fits better, but this is what it was referred to as there.
Whilst this works well for the question at hand, I found it had other problems built in. It was very hard to work across teams, and because of the timescales the design team rarely involved UE in decision making (which put UE in some awkward positions), the apps team and design could be working at cross-purposes, and there wasn't a lot of scope to learn in these boxed in teams.
My suspicion (and I think ideal scenario) is that the developers on a project would each be capable of working with, say, 80% of the technology involved (be it CSS, SQL, whatever) to spread the decision control and risk, but each domain would have one (more?) "czar" who could act as authority and oversight within the domain. Actually producing those designs is to my mind a strange and magical skill in it's own right so I see no real overlap with developers there, but I think a pool of artists and project teams of cross-skilled programmers would be very powerful.
Apols for the long-windedness. I could go on at considerable length on this, I've spent a lot of time thinking about it.
btw, it seems like you could do with some serious web-devs there, (no offence). Having problems to "maintain consistency from one page/component to another" screams failure to grok CSS
In my experience, unless you limit your design severely, you need real coding skills to build a web page with interaction. Let me elaborate some. If you have built your pages very modular (think of GUI toolkit widgets) you can give your designer a handful of them, he can build the basic structure like playing toy blocks with a nice finishing paint.
Often, modularization alone is not enough for desired interactivity. So, some blocks needs their interactions to be designed carefully as well (like animation, fluid layout to accommodate indeterminate content, customized behaviour via extra javascript, caching to eliminate redundant requests and speeding up things) or ability to accommodate minor presentation variations, which brings us to the realm of programming, where you calculate dimensions, enable/disable parts, keep track of time, preload stuff, invalidate preloaded stuff and so on.
Enter HTML/CSS/JS. They are more of a product of evolution than intelligent design. You cannot always declare your intent and be done with it. You need attributes declared in your html, stupid hacks in CSS combined with extra markup, ridiculous amounts of js to smooth rough edges, duplicate rendering code on the server side. These tool were never meant to build applications.
I don't think one can achieve a complete separation of design and application development in these tools at hand. The effort required is too high to justify the marginal returns.
If you end up heavily modifying designer's code (which is othen the case if he is not one of the developers also), there is no point in making him suffer trying to express his intent using the wrong tools, nor developers breaking the design while modifying it and consequently fixing it. I don't even mention user experience.
In my opinion, no small internet businesses who want to ship a product in a reasonable time should spend their scarce resources to go against the grain. Let people do what they do best in collaboration if necessary. If you can't divide design process at an arbitrary satisfying point, you may as well not bother to separate at all. Pipelining works well for machines whose goal is determined to the last detail and not changing. I can't say the same for humans building and designing things be it software or hardware.
Where I work it's basically the same. Designers create mock-ups and specifications of the UI design, right down to the pixel, and the developer creates HTML/CSS/code out of that.
The reason I say code, is that we use UI frameworks (namely, GWT), and as much as we would want to, code and CSS styles are still very coupled. I do not believe there exists one UI framework in which code can be completely decoupled from the UI design.
So I guess for now it's still entirely the developers job. Though I would like to hear about organization which are able to hand off some of the work to designers.
The problem with handoffs is that the idea and implementation of one group is not going to match the abilities and implementation of the next group. Just by their nature handoffs are going to be wrought with problems. So what is an alternative to the ubiquitous handoff scenario? I think that integrating the user experience (UX) into an agile and iterative development process makes sure that what is really important occurs:
The customer's needs are researched then validated.
Early and continuous collaborating between usability experts, designers and programmers.
The actual process works by having everyone collaborate with the customer up-front on their needs. Then the design is researched and prototyped in the iteration before coding begins. Thus when coding is occurring, the next set of designs are being worked on. Programmers should be looking forward at what designers are doing and the designers look back to be sure programmers are on target. Once a design is coded, it goes to the customer for acceptance, by that time the programmers are working on the next set of interfaces.
Jeff Patton did a podcast on Agile UX recently that goes into some of the implementation concepts and common problems.
There is a whole group on Yahoo dedicated to agile usability (which mostly involves interface design).
For the CSS inconsistencies... I'd just suggest making a style guide then trying to stick to it. Have someone be in charge of "design consistency" that way the can spank anyone inventing yet another way to display the user.
At my company, my ideal work flow doesn't work very often, but sometimes it does. I löve when this happens: The engineers write the webapp and output semantic html with only minimal CSS. then you have the designers do the CSS.
I like it when it goes this way, because:
It is easy for me to write semantic
HTML.
I am not very good at coming up
with a good design for my semantic
html.
It is entirely possible to do
the CSS without asking me questions.
The markup just speaks for itself.
However, this rarely works. Because:
The CSS has to be modified whenever the HTML changes and the designers' time is sparse.
Moreover, our designers don't enjoy styling my markup, and fighting for their time is not pleasant.
Our designers often want to change the markup. Mostly because they believe some layouts cannot be done without changing the markup or because they believe that it's the only way to make IE obey. They are technically not able to change the markup, though.
I have my doubts about many of their cases. Many times they claim IE incompatibility, I strongly doubt they really know IE that well. There are neat CSS hacks to make IE obey without resorting to
<br clear="all">
So, sadly, usually this ideal is a little off for me.
A separate designer - developer workflow is the best way to go. Designing a website and coding it are altogether different jobs. There are issues of cross browser compatability, CSS, XHTML, apart from coding standards to deal with.
You could also opt for outsourcing your HTML to a specialized PSD to HTML conversion expert like us (ButterflyHTML). It may work out cost effective in the long run