Related
So I've started a web design course about 4 months ago, it's going smoothly and I'm really enjoying it. I'm trying to learn more in my own time and found tag while searching for something similair.
I don't fully understand it, but I think I get the grasp of it, so basically I'm asking if what I think the cords do is correct.
coords="x1,y1, x2,y2"
Does that create a box, which I can then use a so when it's pressed linked to another page?
I think you're a bit confused.
This function won't perform any doing. In fact, all that is a 'string'. Meaning, if you refer to cords, you will just find 'x1,y1, x2,y2' as the value.
If you're interested in linking content, use 'a' tags. Also, if you'd like to create a nice box, you're going to need some styling knowledge. Remember, as a web designer you create content for the web developer to put together. If you're looking into making the sites, look for a course in 'Web Development'.
I'm a non-developer building a simple Access 2003 database for an NGO that works in developing countries. I would like to provide in-app help (what certain fields mean, for example) in a number of forms and on the switchboard. I'm not sure about the best way to do this - not just on a technical standpoint but to increase user-friendliness. The users are usually using MS Access for the very fist time, and have only basic computer use knowledge.
I don't want to cram the forms with help text, so I'm thinking of adding little question mark buttons that pop up a separate form with just help text. Is that wise?
I've also noticed a Help Context ID property, but it looks complicated (I'm looking for something as simple as possible to implement, so that the help text can be edited as easily as possible by others in the future). I think this is where I'd start if this were the way to go: http://support.microsoft.com/?kbid=209843
This may need to be translated, etc, so again, the simpler the better.
Thanks!
I've built such a system using tables and forms in the FE. You can get an idea by reviewing some of the screen shots at http://www.granitefleet.com/ScreenShots/index.htm I only created general help describing processes where something on a setup form can affect this form. So the user will know where to ge to change something around.
If you haven't built your forms yet, put that information in the table design, using each field's Description. That will propagate through your forms, and will be displayed on the Status Bar whenever a user click in that field.
If your forms are already done, use the [Status Bar Text] and/or the [ControlTip Text] property of your controls.
Just train your users or write once that they should read the Status bar if they need more explanation.
KISS (keep it simple and simple)
Great question. I think the real solution to reducing the amount of work that you need to do is to work really hard on having a simple, clean UI. In the real world there are very few people who have the patience or inclination to read the manual or search the contextual help even in the face of being stuck.
I know this is slightly off topic from the question but if you look at this website for example it keeps the number of things you can do on anyone 'screen' down to the minimum and everything has a tool tip (ControlTip Text in msaccess). Even if site this was in Japanese, I thin i could navigate around it fairly easily and that is because of its simplicity. (I couldn't answer any questions though :P)
Jakob Neilsen has a great site on usability
" I think the real solution to reducing the amount of work that you need to do is to work really hard on having a simple, clean UI. In the
real world there are very few people who have the patience or
inclination to read the man*emphasized text*ual or search the
contextual help even in the face of being stuck.*
Regarding this, it really depends on the application. It is overly simplistic to assume that every application can have all the information it needs to be operated just by having a simple clean UI, especially if in the name of being simple, there are alot of useful features that are not included. In certain complex applications, people will simply need to have patience and read the information available or they will waste a lot of time guessing. It is better to have have information at the press of a button than have them asking for it once they figured out that they are wasting time figuring it out with no help. I agree that many apps are way more complicated than they need to be.
I have a horrible habit, actually something I'm wrestling with right this moment, when I think of a better way to do something - either a refactor, or something that would just be SO MUCH COOLER LOOKING, or such a better UX, I just HAVE to do it. Even when it would cost me time and I'm in a time crunch. I never know when to say, "no, there isn't time for this I can do it later."
Is there a line you draw?
Like right now I need a way to display magazine articles that are in the database. The easy way would be to create a new .aspx page and just pass the article id. the AWESOME way would be a jquery fade in modal that would display the article. At least that's what I think. Not being a guru it would take me longer to write. We are launching next week no time for extra crap. However, I just can't bring myself to do it the easy way.
Does anyone else run into this problem? Wondering if more experienced programmers have some wisdom to share.
I'd go the quick route first.
Write an ASPX page that is showing an article based on ID, or even cooler and more SEO-friendly, a slug. You'll be able to meet your deadline. Then, I'd start on the awesome jQuery way.
The bonus to this is that you'll have a fallback option, in case that a user has JavaScript disabled.
You're talking about "gold plating". It's a very common and well-known issue for software developers.
From the glorious founder of StackOverflow himself:
30: Developer gold-plating. Developers are fascinated by new
technology and are sometimes anxious
to try out new features of their
language or environment or to create
their own implementation of a slick
feature they saw in another
product--whether or not it's required
in their product. The effort required
to design, implement, test, document,
and support features that are not
required lengthens the schedule.
The proper way to cure this problem is to volunteer for so much work that you don't have time to do it right, let alone add on extra bells and whistles. :)
Edit: Other "classic mistakes" link here.
I think it's just a matter of setting priorities. Also, if your client, or boss doesn't want you to do things the flashy way, and you don't really have time to do it the flashy way, just do it the simple way, and come back and upgrade to flashy if you have time later. Clients and bosses are usually happier when you finish the work they gave you before moving on to making things better.
I look at how much time I have left, and if I feel I am pressed, I don't venture outside of my area of expertise. I am all for doing it correctly and elegantly, but the reality is that the majority of the time the deadline takes precedence, and I know if I stay within my comfortzone when pressed, I will most likely make fewer errors which means I save the QA people time in testing things.
That all being said, I have been known on more than one occasion to push the limits of how much can be done. If you aren't working an immense amount of overtime already, you can always make extra the time necessary for going the harder route. Yeah doing this can cause a little more work for extra people but sometimes that's the difference between having the best application or having the first loser.
My other advice is don't try and do both options. If you create a basic version stick with it and move on. If you try and do both, you're really wasting time in the end.
The right way is to have it functioning so that users can get to the information they seek. The designer way is to have it kind of working but also have javascript light things up and move around.
The best way is to get it working correctly then revise it. There shouldn't be much refactoring involved if you know where to place things. Obviously retrieving the article is going to be business/app logic and the actual fancy design (like fades/animation) will be part of the design/view aspect of the setup. These portions should be able to sit and be somewhat ignorant of what the other is doing - they shouldn't be tightly coupled.
Sounds like typical feature creep. Convince yourself that tabling a feature idea now to meet a deadline is quite different from simply dropping the feature altogether. You can come back to it months after release and put in new features.
I think you've pretty much answered your own question there. You said that adding this feature would take too much time, and you're in a time crunch and are launching next week. I think it's fairly obvious you need to go the "easy" route.
You're basically describing feature creep. http://en.wikipedia.org/wiki/Featuritis
You need to discipline yourself, what I would do in your position is document the new feature I want to add, and implement it after your out of crunch mode when you have time to work on it. You're obviously aware that adding this feature is going to cost you time and may very well set back the launch of this product, you just need to have the discipline to prioritize and stick with it.
I think every developer has this problem if he is interested in programming and isn't coding just as a way to make money in a 9 to 5 office job.
Here is my advice:
Make a list of every cool thing you think of as you're writing the code. After you have a working basic version, commit it to your source repository.
Now if you have time left go back and do as many cool things as you have time for. Use branch tags if you're going to have to seriously rework the code.
Once you run out of time, if you're doing Agile, write the leftovers up as stories and give them to your project manager or client.
I think when you say you are doing something the "right way" that implies a balance of quality with the speed you can write it in.
If you make something as high quality as possible, but never release it, it's not the "right way". On the other hand, if you write crap but get it out super fast, that's also not the "right way." To do something the "right way", you must balance these two.
An economic phrase that comes to mind is "Quality, Price, or Production Speed, pick two."
Things like this used to absolutely kill me!
Here's my advice:
Do it the easy way (the aspx with the
id parameter)
Write a small proof of
concept to show the client
Show the client the working page and the proof of concept later along with an estimate on how long it will take. The experience of designing the prototype will give you a better idea of what is involved, how to do it, and how long it will really take. The proof of concept can also inform maintainence developers what's what (fading vs logic), and allow them to issolate if the fading mechanism or logic is broken.
Personally, I would stay away from the fading thing. In my experience the client will see no added value in the fading functionality and IMHO seperating it to another page will be easier to maintain. I believe it will be less prone to bugs later since code for the 2 pages will not be intermixed onto one page (if I understood you correctly).
In test driven development approach, when you implement a feature by writing a test for it and implementing it the easiest possible way, you will be able to go back and do it "right" only when you find really need to do so. Knowing this allows you to avoid overdesign. And often, you find you won't need to after all.
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!
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 7 years ago.
Improve this question
I'm supposed to do a presentation for my co-workers on a web framework I evaluated. These people are developers and hate long and boring PowerPoint stuff, so I got lots of little code snippets. I also put together a small sample application. My question is, how do I present the code so people can follow?
Some things I thought of:
Put the code on PowerPoint slides, looks pretty bad and unless it's an image I can't get syntax highlighting to work. Having my code in images is a pain and doesn't scale well to different resolutions.
I played around with the S5 XHTML presentation format and integrated a JavaScript syntax highlighter. It's a bit clunky but workable (I'll get some grief for ignoring the company's CI for presentations since I wouldn't use their templates. Don't even ask...)
I could put together a script (notes) and "live-code" in front of my audience. I don't like this so much because it keeps me so busy that it's hard for me to give a good explanation while I write. And there's also a high chance of me causing errors and make them wait.
A screencast? But then I wouldn't have to be there... Maybe narrate it?
So what would you do?
I could put together a script and
"live-code" in front of my audience. I
don't like this so much because it
keeps me so busy that it's hard for me
to give a good explanation while I
write. And there's also a high chance
of me causing errors and make them
wait.
I like this option, if you can get your demo streamlined to the point of not holding up the audience. You can do what TV cooks do when the recipe takes more time than they have; start the coding, then jump ahead to one that's 90% or 100% done.
If you have a colleague you can get up to speed, you can have them do the coding while you talk and point out what they're doing.
You can use your IDE, which will give the syntax highlighting and show your audience how to compile, deploy, test, etc. I would recommend using an oversized font though, just for the session, so that everyone can see.
Does your IDE allow opening/closing regions or code segments? In Visual Studio you can create code regions that you can expand or collapse. If your IDE has the ability to do this you could create your code samples as regions and then open/close them as you go through your presentation. You could switch back and forth between your presentation and code samples in the IDE, but wouldn't have to code on the fly. Using open/close allows you to hide the code you're not referencing to keep things less cluttered.
I actually saw this done at Agile 2008 and it seemed to work pretty well.
You can only fit so much information on a PowerPoint slide but that's actually a good thing: people can only look at a certain amount of information and get something meaningful from it.
So if you can't fit it on a PowerPoint slide, you need to rethink your approach.
Code snippets are good. They don't need to be highlighted. Just put them in Courier New (or some other fixed width font) and it'll come across as code. Code snippets don't have to be complete either. Just boil them down to the essential concepts (using comments or ellipses to indicate missing code).
Programmers being programmers, they'll probably ask questions when it gets to the technical, which is good.
Also, if the programmers are familiar with something similar try and relate all the concepts back to what they know. It makes it easier to grasp. Like if you're explaining Spring MVC and they know Struts, explain the Struts equivalents. It can be useful to put that sort of thing in table form (even as a handout).
That's what I did for exactly that (a Spring MVC primer for Struts programmers).
If you want your audience to see a lot of code snippets, especially lengthy ones, you could print them out as handouts or provide them as notes in PDF or text files (people can follow along on their laptops).
Actual presentation slides should contain the smallest amount of text (including code) necessary to convey your ideas. If there's a lot to read from a distance, your audience will get tired after awhile and might have trouble following along. Let people read the full code sections on their own laptops or handouts, while calling attention to just the critical parts in your presentation slides or script.
If they don't like Powerpoint, don't use use it. We use Camtasia screen recording to record 'live' demos for presentation to customers (live in quotes since it doesn't have the disadvantage of crashing halfway through your presentation :-). They always prefer to see it in action rather than what they think is fudged functionality.
It's pause-able like your Powerpoint slides and has the advantage of syntax coloring since you just record bringing your up in your favorite editor. It's also dynamic which is much better than Powerpoint (although I've seen some people do crude animation with multiple Powerpoint slides, always funny to watch in action).
This basically maps to your screencast idea but, if you want a reason to be there, do a large number of small screencasts to show interspersed between your real presentation, narrating (in person, not on the screencast) if necessary.
Personally, I'd prefer to send a fully narrated Camtasia off to the target audience but that's because I'm not totally over my early-career phobia of public speaking :-).
In a pinch, you could do a real live demo since your audience (is videance the equivalent for video presentations?) are programmers and will understand any problems you have.
I had this done to me, and thought that it was the best possible solution:
Get another person to help you out. While you are talking about the code, let the helper type the code. This way everyone in the room will be looking at the code, while listening to you explain it.
This of course involves finding someone who can help out, and understand the code just as well as you do. But the results can be great.
If you could do it all in a screencast and you wouldn't have to be there, then do a screencast and don't be there. Nobody complains when a meeting gets canceled. Just distribute the video, maybe with an accompanying report with notes or links so people can read more about the tools you're demonstrating.
And you'll get more credit later as your co-workers and managers talk to other people: "Hey, did you see the presentation Bibac did? No? You should; I'll send you the address after lunch."
If you're demonstrating code in the presentation, then also consider having the finished project available so people can try it for themselves.
When I give presentations involving Visual Studio I put code snippets on the general tab of the toolbox. During the presentation I drop/drag these code snippets into a code file, markup page, etc.