Related
Background: I'm having to build a bunch of similar pages*, 50 or more. They share a lot of design and content so I will be encapsulating/reusing as much of the styling and content as possible. Still, each page has unique elements and may have arbitrary design elements, so the pages can't just be manufactured programatically from a database or resource file.
What might help: Because there are so many pages to keep track of I would like to edit them in a big table rather than in a long scrolling text file or in separate files. That would make it easy to compare and contrast the code for each page. The table would look something like this:
| Group | Page name | Description | Formatting | Header | Body | Footer |
|-------|-----------|-------------|------------|--------|------|--------|
| 1 | Page1 |text |code |code | code | code |
| 1 | Page2 |text |code |code | code | code |
| 2 | Page3 |text |code |code | code | code |
The first three fields in this example are for my own use or maybe would go into the pages as metadata, while the remaining fields show where the 'real' code would go.
Questions:
Am I on the right track with the idea of editing the page code in tabular form? Are there established better ways to set up a whole group of similar pages together?
If tabular editing does make sense, what tool should I use?
Tools I've considered:
Text/code editors: Ok, no surprise, but I haven't found any code editors that let you display and edit a file as rows and columns defined by, maybe, special tags. Does anything like that exist?
Spreadsheets and structured databases: great for basic rows and columns, but terrible for text editing, and display of multiline rows is lousy.
A specialized "structured text" database: Maybe one exists, but my searches came up empty. Most 'text databases' are for unstructured/freeform text.
"Table editors": wrong idea, correct? They're for generating code for table structures that you then display on pages, or use in database forms or reports.
Word processors. For now I'm going with a table in Microsoft Word, treating the HTML as ordinary text. With the page width set to Word's max (22") and the font really small, there's plenty of room for the columns I need. I lose all the help a code editor provides and that's a big loss, but at least I can see what I'm doing. Word has a keyboard command that lets you move one or more rows as a block up and down in a table, so that helps for comparing pages. But another major downside is that I will still have to export the table to a CSV using a Word VBA 'macro,' then write a little script to loop through the CSV to create the actual pages. I haven't coded those conversion routines yet, so if you have any alternatives to suggest, please do.
*The 'pages' for this project are actually Anki card types.
Nested files
What I've done before is to build each page or page element as a distinct file, then reference that file from another page. This ends up in nested files, but it makes editing pages in a normal text editor much easier.
________________________________________________________________________________
| Header file |
| Scripts file (or reference) |
| Body file |
| Navigation file | Content file |
| | More Content file (reference from Content file) |
| Footer file |
________________________________________________________________________________
This can get nested pretty deep, if you need, but it doesn't have to. And you can get these references pulled from a DB instead of having them hard coded in logic on your site, like normal, but I'm not sure how this would really work with Anki cards.
Content management sysyem
If you really need/want to store your pages as code/text in a database, I'd recommend building a content management system (CMS) for yourself. This involves a lot of work up front, but it'll allow you to do all the work you want to do and store it in a DB.
I've written a couple for myself and my website customers, and it's a long and difficult process most of the time. You have to think of literally everything you want to do. Essentially, you're recreating FrontPage or DreamWeaver and you'll probably do just as bad a job as they did, unfortunately. Maybe worse. At least I did.
If you don't do anything graphically in this CMS, it'll be easier to develop, but you'll still have to manage your links manually, sort of how StackExchange/StackOverflow works: a text box for code with a line of basic "advanced" features buttons above, with a half HTML and half MarkDown syntax that can easily get confusing or features lost due to not using them very often.
Website builders
If you weren't using something as specific as Anki cards already, I'd suggest using something like WordPress or Drupal. That's basically what they do: store pages as rows in a DB. Of course, many of the pages are built using a GUI, but some people build pages programmatically.
If you're like me, you'd rather stick to hand coding everything. Wordpress has security issues and I'm pretty sure Drupal and all the others do too. The plug-ins people make for them seem to rarely care about security, so a site built with these tools are usually vulnerable, unless you have your site hosted on their servers, which is often also not a preference. Also, you end up managing plug-ins when they update more than actually doing development, or so I hear from people who do this professionally. You might be able to write your pages there, then dive into the DB to copy the results out, but that seems like a less than desirable way to do things, too.
Conclusion
So it seems as if building your own solution seems like the best of the lack of options you have. With building the CMS, though, you can have the code instantly rendered, like SE/SO, as well as do side-by-side comparisons in the same window, if you want. And you have the capability of making it as simple or complex as you want, along with adding or removing features when you want.
Again, this isn't likely to be easy, but it's more likely to be what you want/need than what someone else imagines might be helpful to people in general. And if you make this CMS useful enough, you might even be able to market it to others who use Anki cards. Just a thought, though.
My Question is around usability. In most of the sites i have seen and developed i see taxonomy as a way a user would find something he is looking for in the site. But quite recently i have seen the concept of tagging. Where products services questions are tagged and can be found with the tagname. Is tagging an alternative to taxonomy or they should work together.
I'd say that like most things, it depends on what kind of information you're trying to organize.
For example, here on Stack Overflow, there isn't really a rigid hierarchy by which to sort the questions. They're much more organic in the sense that they can span multiple, and even unrelated, disciplines or fields and create a whole host of dynamic connections. For organizing this type of information, I think tags are an appropriate replacement for traditional, hierarchical taxonification. The decentralized, dehierarchized nature of tagging dovetails perfectly with the general organization of the site's content, especially when the site's users/community is encouraged to participate in cataloguing and organizing the information. Many blogs and social networking sites like Delicious organize their content with a series of tags as well.
Conversely, if you're trying to sell products or provide technical support, you'll probably find that tagging is not a suitable replacement for traditional taxonomic organization. If you're familiar with MSDN, which provides online documentation for developers in the Microsoft ecosystem, you'll observe that most of its content is organized into a natural hierarchy by technology/language, feature, sub-feature, etc. If you want to buy a computer from Dell, you start by narrowing down your choices: do you want a desktop, notebook, or tablet? Do you want a performance-oriented notebook, a desktop-replacement notebook, or an ultra-portable? Etc. Of course, that doesn't mean that you shouldn't consider implementing tags as an alternative way for users to explore the information that you have available, but in the best of cases, they will work together.
Think about the type of content you plan to host on your site and consider the most natural way to organize that information. Your users will appreciate more than anything a site that is intuitive and where they feel it is easy to locate exactly what they're looking for.
That is an argument I always found interesting, and basically I reduce to this question:
In order to found something, is better to have a hierarchical taxonomy or a flat tag-based taxonomy (maybe collaborative i.e. Folksonomy) ?
Well, there's no unique answer, but, depending on the search context, sometimes the former is more convenient and sometimes the latter is.
The best thing would be to have both kind of taxonomies, but could be difficult to manage, in particular if contents are created by people and so the classification is up to them.
One solution could be have tags inheritance, like in drupal taxonomy system.
So for instance when you want to classify a picture of your dog, you just have to select the tag: 'dogs' and automatically your picture will belong to tags: 'dogs' --> 'animals' --> 'living beings' and so on.
This question is an issue related to the human thinking:
Sure it is better, if you can find something by a tagged word. If you dont know the word/tag perfectly, you are not able to find it. Others may have taged the thing you search for with a similar, but other tag. In this case a (binary) tag search will not give you the correct (or whole) awnser.
Anyway, there is a possibility to extract a taxonomy (as long as words/tags are related) out of tags. This concept (combined with a vecor-orientated-search) can be presented to the user and will help him to find what he needs.
Although I'd just upvote Cody's answer (I did), I would also like to add something:
The field of usability used to be within the realm of ergonomics before it grew up. So I think it is appropriate to refer to one of ergonomics' core principles.
Every person has a unique set of dimensions, so there is no single set of “correct dimensions” for e.g. a chair. The best dimensions are adjustable dimensions that provide a reasonable range of variability.
It is possible to apply this principle to website navigation as well and provide multiple ways of reaching the same content, so that people with different habits can find stuff using the way they are most comfortable with.
What are pros and cons of this technique (see Softfolio for an example). Two things I personally thought of are as follows:
Impossible to tell someone where an item of interest is located (like, you probably won't say "324-th row, second column")
Broken navigation when you return back to an infinitely scrolled page.
What else can you think of? And what do you personally think of this approach in general. Would you use this in you projects?
I think it is "neat" but requires more visual clues as to what is going on... and in many circumstances isn't what the user wants.
If I want to get to "page 7 of the results" I don't want to move to the end of the page 6 times to trigger the reload of additional data. (e.g. in an alphabetical list... If I want "M"'s, don't make me wade through a,b,c,d,e,f,g,h,i,j,k,l
Ensure there is a visual clue of more loading if you do use this (when I press CTRL+END I expect to be at the bottom)
I often find I'm still waiting on these types of pages because the "loading" of the next set of results waits until I'm very near the bottom... thus I often get there before the data is loaded/ready/rendered
(pro) I think this kind of thing would be good for certain scenarios... e.g. when I scroll down my Twitter list... I don't want a "more" button, just load it...
I would prefer better "search" filtering over fancy ajax-infinite scroll results. If I can filter down to 25 results that actually match what I want, then I won't need to scroll!
When results are served randomly, it's a great idea. People are asking, "How do I get back to where I was?". Well, you don't. The results are random, so when you return to page six, you won't be seeing what you did last time.
If you think about it, paging Sortfolio would be a bad idea, because it would imply to its users that the order of its listings are fixed, as many of you have made the mistake of assuming.
For those asking, "How can I return to a result I liked?", well, you click the 'Save to my favorites' link. As for, "How can I share a result with a friend?", you click on the result and grab its URL. Kinda simple really.
I'm not saying this infinity-scrolling business is the way to do it, I'm just saying that some of you guys are unfairly discrediting Sortfolio for usability problems which the site—given its random nature—really needn't concern itself with.
Personally I HATE that example. It makes the site much less usable than if the results were paged.
You're right too, when you hit back, you will have to page by scrolling down again, and while page down works it doesnt work well - I cant remember how many page downs i pressed to get to the site, secondly, what if the ordering changes the number of scrolls would differ anyway - I know paging would too, however its much easier to scan a few pages than keep scrolling.
Lastly, even though I am a developer I scrolled down, and the first few times I actually thought maybe if i leave it long enough it will download all the images/samples...then scrolled down and again the same thing happened AAAAAARG!
I would NEVER use this approach in projects.
I wouldn't use infinite scroll on search results. But it's really nice for casual browsing, or in a random output situation such as psychological test where it's important that items not show up in a constant order. Something like a market preference survey skews towards early choices, so randomizing the order of options is essential.
Where it gets frustrating is when the user leaves a page via a link and then wants to come back. For a browsing situation, I'd probably address that with overlays rather than linking away.
I personally find it gimicky and quite annoying. It diverges from standard navigation techniques that users are used to (such as pagination) and breaks navigating back, which is very annoying (you can't get back to a result without starting again). On top of that it doesn't conform to accessibility guidelines as it is totally reliant on JavaScript to work (which goes against the "progressive enhancement" theory of the modern web). This also has SEO implications as I doubt content "beyond the fold" would be indexed, unless it was linked to directly from elsewhere.
I can see a few limited circumstances where this might be OK, such as a very long text page, but personally I doubt I'd use it in the current form. Kind of reminds me of those Flash sites that are all style and no substance and end up annoying the user rather than enhancing their experience.
I agree this is a mess. If there is a finite list, there should be some kind of pagination mechanism that lets you know where you are.
Alternatively, or in addition, add a filtering mechanism so you can weed out the stuff you don't want to see.
SO provides a handy example of how to do it right.
Actually, It doesn't matter whether we (designers/developers) like it or not. The only thing that matters is the users perception of this. If the user finds it useful, well, then the solution is OK. If the user gets confused and can't accomplish the primary task, then redesign...
I think the cons are that when you hit the back button you lose your place on the page. Could be annoying especially if you are deep within a page.
Etsy discovered the hard way that infinite scroll isn't good for conversions. Recommend reading this article.
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
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.