In Interface Builder I have a bunch of text fields that sit vertically. I want them evenly distributed in the vertical space, and all to be identically sized.
I've found the Alignment menu that lets you line up items. I can't find a menu for distribution or sizing. Does Xcode 4 include those layout commands?
The answer is, NO. And I HATE having to be "one of those people" that has to tell you so. I assume what you are looking for is something similar to OmniGraffle's quintessential feature, "Canvas, Grid, Alignment". It is THE TOOL that makes OG so damned good.
It amazes / disgusts me that a company worth $100 billion is unable to get this basic tenet of visual layout right, when a company writing software for that same idiotic company's own platform for years, has had this down for as long as I can remember. The Xcode team needs to pull it together. For example, KVO Bindings are, and have always been a joke - a not so funny one - that are impossible to implement, plug-ins are gone… And IMHO, Lion auto-layout is Unusable. They need some NEW PEOPLE or something, maybe that aren't developers, or something.. Cause Xcode is getting harder to use, not easier. It looks better, and is better organized… but its obvious that there is no "big thinker" inside that group that is willing to question their fragile and awkward paradigms.
Are they kidding with this? How about this Xcode? _Shut up, line up the buttons, distribute then evenly - like 99% of people are going to want, 99% of the time - and dont puke meaningless lines all over everything?__ And what the hell is Content Hugging Priority and Content Compression Resistance Priority? I read the docs twice and still have NO IDEA what those are or how to use them. I'm no Einstein, but If I can't "get it" after making a concerted effort… It's too hard. lol. Ok, I need to go mark futile rant off my to-do list, now.
Hope this helps: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutbyExample/AutoLayoutbyExample.html
The concept is to use some spacer views and set them to be all the same size. There are some tricks with the priorities to be done so please follow the link for a definite answer.
The boring answer is to type in the coordinates manually. Not very smooth, but it gives you exact control over the placement at least (in the Size inspector).
Related
I'm making a timeline with relatively small bars representing events over time. Right now they are roughly 8px by 200px (the length is variable, but all are 8px high).
Is there a standard reference for what size is standard or minimum for what types of interaction? For example I just want a mouse-over on these bars to highlight them and provide a tooltip, where I imagine if I expected a user to click on these bars, a bit bigger might be more realistic.
Anyone have any insights on this?
It'd probably be pretty hard to find guidelines specific to what you want to do.
There are several things you could do. Wikipedia has a nice article on usability
My main advice would be to think about what your users need, and what they are capable of using/learning. What you could do is make a few different versions where you change a parameter (such as the height of the bars) and get different people to test each one.
Personally, I would be happy to use bars that were 8px high. I would not be so happy to do this if I was using a touch screen.
You should think though, is it really necessary to fit that much information on one screen? How many bars do you think would be appropriate on average to be able to fit in the vertical space of the screen? Perhaps you could have two modes - large and small, where large fits 30 rows, and small can fit many more.
But it's not really something you should be too concerned about at this stage. Just make sure that it is easy to change it later on, and you won't have to worry about it now. User testing should sort out the problems - as long as you listen to there needs (or watch them, see the mistakes they make, and try to fix the most common ones).
One thing to remember, is the "rule of 7", which basically means people are more comfortable looking at less information, as too much information can overload the brain (but it really depends on the target audience, for instance, an historian may rather see as many concurrent events at once).
A requirment has been given that the desktop icon change colors "to fit well" with the users chosen desktop color. Not only is that a vague requirement but it is not the standard way that applications behave. The correct solution is to provide a number of icons which the users can select from. I just think its a bad idea. We are in the requirments phase still and I feel like I am becoming antagonistic. Standard practices exist for a reason but I am about to lose my cool because fully 15% of the 300 requirements fall into this category.
defer the argument by putting this on a "nice to have" list (that will never get implemented because it adds nothing to the functionality and creates disproportionate configuration problems) and concentrating on the real features that actually do important things
suggest a transparent icon so that it blends exactly with the desktop colors (see if they realize that it would be invisible!)
give a very long list of why this feature is ridiculous, create enemies, make the customer/manager feel stupid...not really recommended
bear in mind that you may be dealing with people that mean well but don't know much technically. Say "that's an interesting idea" to validate their feeling/input/existence, and go on to more important things. ;-)
Say for instance I'm going to do some seat of my pants coding adding a feature to an enterprise app. What are some good examples/tenants/cardinal rules a person can follow for making a fairly complex setup/config screen not look like feet.
What I'm looking for is along the lines of "Don't put one thing in a group box". But I'd also like some help with symmetry if anyone knows what layouts are most likely to achieve a relative amount of good looks that would be helpful.
Here's a cardinal rule you asked for: line up the controls vertically /horizontally and equally space the various related elements. And use correct spelling on your labels!
We've all come across screens where there are misaligned controls (even a couple pixels is noticeable) or misspelling on labels. When this happens to me I can't help but subconsciously look for other mistakes, plus it decreases my confidence in the application I'm using!
This is actually a huge topic. I frequently go to the Microsoft UX Guide for reminders on how to do this.
Some basics:
Make your app read like a book: left
to right, top to bottom
Use goal-oriented language instead of
technology oriented language
Not a cardinal rule but a great resource:
Apple UI Guidelines (good info for any OS)
EDIT: Re: achieving symmetry - things don't have to be perfectly symmetrical, but you want a feel of balance. Take a step back and get a sense of whether the page or form feels like it's leaning/falling to the left or right.
E.g., with stackoverflow, the main content is to the left, but it's nicely balanced by the extra stuff on the right.
I find that paper is my friend. I like to write out a list of objectives the form has to accomplish, and then sketch the form by hand, labeling the parts. Drawing it out lets me get away from making sure it looks perfect and that everything is aligned just right, and lets me focus on making sure that all the components I need are placed, hopefully somewhere logically. It also forces me to lay out the UI twice, so by the time I open my UI designer, I've already designed the form once and you hopefully know what I am doing
Some basic rules for you.
Try to make effective use of whitespace. Don't cram everything together in an effort to get as much stuff on screen as possible. This will make grouped controls more clear and text more legible.
Basic typography. Limit your use of fonts to 1 or 2. Don't use bold too much or it loses its emphasis.
The same goes for colours. Don't use too many, the fewer the better most of the time.
Don't just use icons to save space. Tiny icons with no explanation are useless.
Copy. Not wholesale of course, but if you are not well-versed in UI design yourself, it makes sense to take elements of interfaces you know work and apply them in your own designs.
Be clear about the purpose of the interface. How does it fit within the broader application for example? And what are the specific objectives you are trying to satisfy with it?
Get people to test it for you, early and often. I don't know what setup you are working with, or what kind of organisation you are in, but getting some kind of human feedback on your work will always be helpful, even if you lack the time and expertise to conduct proper usability evaluations.
Since you use the term, "seat of your pants," I'm assuming that you don't want to spend too much time on the UI. If you are willing to devote some time to the UI, you may want to look into custom control or UI development that will suit your situation. Like Firefox's Options UI or the .NET project properties in Visual Studio 2008.
If you are looking for something using standard controls, it is probably best to separate out different sections of related items into tabs or some other type of stacking control (i.e. Ribbon control). A good example of the tabbed version would be the Notepad++ Preferences UI. Many other programs use a similar scheme.
The best way to get a UI that makes sense is to follow Joel's advice:
Eat your own dog food.
Do it a few times to your own UI, and you'll notice some things you didnt think of intially.
I've found that a really good test is getting someone non-technical to use your GUI. Watching someone use it for 5-10mins normally gives me a very good idea about what is/isn't easier to understand.
This series by Joel Spolsky is a pretty good read and Jakob Nielsen's stuff Usability and Web Design is pretty useful.
Specific rules I try and use are:
Put items in logical groups
Line everything up
Use sensible images/icons
Spend 5-10 mins thinking through why things are the way there are
Only use words that make sense to the user not to you!
Start from the setup/config UI of an existing application that you feel is both simple and usable.
Most tenants/cardinal rules apply to UI in general and fill hundreds and hundreds of pages in UI design and HCI books, so you probably want to just work your way by example for now, while trying to capitalize on existing user experience (habits), i.e. obeying the rule of "least surprise": e.g. if your application is a Windows application, use the Installation Wizard pattern, if it's an ncurses app for a particular flavor of *nix follow the style of that particular OS's actual installation UI, etc.
You might be interested in the book "Don't Make Me Think," (author's web site) or "About Face 3.0". Both come highly recommended for reading about how to design interfaces.
I'm a computer science student designing a project and I've started wondering what are good examples or software, or even hardware that are toeing the line between being feature rich with good usable features for regular users and being too intimidating for new users. Also could anyone recommend any good tips/books for designing good quality applications that are feature rich but not "bloated"?
"Make everything as simple as possible, but not simpler." - Albert Einstein
"Perfection is reached not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry
I am not trying to be flippant but these quotes really are the best advice. Simplicity of design should be your goal. Not that achieving simplicity is easy! On the contrary, it is quite difficult but it is possible.
Try thinking about things a bit differently. Rather than
How many things can I add before this becomes bloated?
try
What are the fewest number of features and elements I can include while still providing a superior experience for my users?
Here's a good set of slides from a presentation on the topic: Rescue Princess 2.0.
The first order of business should just be keeping the application easy to use. Beyond that, all I can say is, beware of writing features for an imaginary user: make sure someone actually needs it before you start coding.
As a direct answer to your question: pretty much any Microsoft product. I'm showing my bias here, but Microsoft has a strong tendency to keep their codebase, and add features on top of features until the original functionality of the app is nearly lost beneath mounds of accreted crud.
Look at MS Word, for example; while you can still just open it up and start typing, god forbid if you want to renumber a section of your document while leaving the rest alone. Heaven forbid if you want to generate a Table of Contents that includes references to an Appendix. This sort of stuff is something that is de rigeur for Word Processors, and Word supports it, it just supports it in a way that you cannot get it done without a manual, several cups of coffee, and bandages to stop the bleeding from banging your head on the desk.
Microsoft isn't alone in doing this; this thing tends to happen all the time, with all sorts of products; but they are among the worst offenders, I've found.
1: What do your users need, and want, and
2: Which features will you have time to implement?
Your question is pretty general. Which features constitute bloat? That kind of depends on whether you're writing an antivirus scanner, an OS or a word processor.
There is no clear barrier between "good" and "too much".
However, it depends on what you want to do.
If you're developing a SDK, I recommend splitting your implementation in several small libraries(rather than just one big SDL library, there is the SDL core, SDL_Mixer, SDL_Image, etc.)
If you're developing an application, keep a module-based system and a plug-in mechanism.
That way, new features can be added more easily and bloat can be more easily detected.
You may get to a point where you'll add new features some will consider "great" and others "bloat". Otherwise, your application may reach a point that some will call it "feature-poor" and others will call it "just enough".
This isn't an exact quote, but the idea was something like this:
A piece of software is perfect not when there is nothing more to add, but when there is nothing more to remove.
In essence, the simpler and more to-the-point is a software, the better.
To get examples of good software design, take a look at programs that are popular today. Google applications would be a nice place to look. Skype perhaps. Heh, even StackOverflow. :)
If you want intimidating, go to the world of CAD. Check out for example Blender. That's a freeware 3D designer software. Good tool I'm told, but the UI has so many buttons/panels/menus/etc. that it makes baby bunnies cry. Unfortunately I cannot say if this would be a good example of a "bad" UI. 3D designing is a very complex process and all those tools are probably in the right place. But it's definately intimidating. :)
A bad UI design can often be found with propieritary software that comes with propieritary hardware. Unfortunately I cannot give you any examples from the top of my head.
I always tend to design my projects in a way that they're just skeletons which are as extensible as possible. Limiting factors are performance, complexity or Thirdparty-limitations.
This way you could add additional features after finishing the basic structure. A user could also add his needed features.
This probably does not work very good for GUI-applications which should have a good usability without much configuration, but I'm sticking good with this approach for those libs I develop. (They're used by other coders who like to have a highly modifable piece of software)
It's not very hard to develop an application/lib which is bloated with features. But it is to develop an app which could be easily extended by other developers/users to match their own needs.
Develop a wide-ranging plug-in system so you add and take out stuff at any time. Problem solved. If only that was as easy as writing spaghetti code. ;)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am planning to give a Technical presentation for a product we are building.
Intended audience is Technical developers. So, most of the time, I will be debugging trough the code in Visual Studio, performance analysis, some architecture review etc.
I have read couple of blogs on font sizes to use, templates to use on Visual Studio, presentation tools, among other very useful tips.
What I am looking specifically for is how to keep the session interesting without making it a dry code walkthrough? How to avoid making people fall asleep? Would be great to hear some stories..
Update1: Nice youtube clip on zoomit. Glue Audience To Your Presentation With Zoomit.
Update2: New post from Scott Hanselman after his PDC talk - Tips for Preparing for a Technical Presentation
Put interesting comments in the code.
// This better not fail during my next presentation, stupid ##$##%$ code.
Don't talk about them, let them be found by the audience.
-Adam
FYI, that Hanselman article has an update (your link is from 2003).
Use stories. Even with code examples, have a backstory: here's why someone is doing this. To increase audience participation, ask for examples of X where X is something you know you can demo, then phrase the walk-through in those terms.
Or maybe you have war stories about how it was different or how it normally takes longer or whatever. I find people identify with such things, then as you give your examples they're mentally tracking it back to their own experience.
I recommend Scott Hanselman's post (previously mentioned). I've written up a post with some tips, mostly for selfish reasons - I review it every time before I give a technical presentation:
Tips for a Technical Presentation
If you're using a console prompt, make sure the font is readable and that your paths are preset when possible.
Take 15 minutes to install and learn to use ZoomIt, so your audience can clearly see what you're showing off. If you have to ask if they can see something, you've already failed.
Probably most important is to have separate Visual Studio settings pre-configured with big, readable fonts.
One of the best pieces of advice I ever got for doing demos is to just plain record them in advance and play back the video, narrating live. Then the unexpected stuff happens in private and you get as many stabs at it as you need.
You still usually need some environment to use as a reference for questions, but for the presentation bit, recording it in advance (and rehearsing your narration over the video) pretty much guarantees you can be at the top of your game.
I also like to put small jokes into the slides and that recorded video that make it seem like the person who made the slides is commenting on the live proceedings or that someone else is actually running the slides. Often, I make absolutely no reference at all to the joke in the slide.
For instance, in my most recent demo presentation, I had a slide with the text "ASP.NET MVC" centered that I was talking over about how I was using the framework. In a smaller font, I had the text "Catchy name, huh?". When I did that demo live, that slide got a chuckle. It's not stand-up worthy by any stretch of the imagination, but we're often presenting some pretty dry stuff and every little bit helps.
Similarly, I've included slides that are just plain snarky comments from the offscreen guy about what I'm planning to say. So, I'll say, "The codebase for this project needed a little help", while the slide behind me said "It was a pile of spaghetti with 3 meatballs, actually" and a plate of spaghetti as the slide background. Again, with no comment from me and just moving on to the next slide as though I didn't even see it actually made it funnier.
That can also be a help if you don't have the best comedic timing by taking the pressure off while still adding some levity.
Anyway, what it really comes down to is that I've been doing most of my demo/presentation work just like I would if it was a screencast and then substituting the live version of me (pausing the video as appropriate if things go off the rails) for the audio when I give it in front of an audience.
Of course, you can then easily make the real presentation available afterward for those who want it.
For the slides, I generally go out of my way to not say the exact words on the screen more often than not.
If you are showing code that was prepared for you then make sure you can get it to work. I know this is an obvious one but I was just at a conference where 4 out of 5 speakers had code issues. Telling me it is 'cool' or even 'really cool' when it doesn't work is a tough sell.
You should read Mark Jason Dominus excellent presentaton on public speaking:
Conference Presentation Judo
The #1 rule for me is: Don't try to show too much.
It's easy to live with a chunk of code for a couple of weeks and think, "Damn, when I show 'em this they are gonna freak out!" Even during your private rehearsals you feel good about things. But once in front of an audience, the complexity of your code is multiplied by the square of the number of audience members. (It becomes exponentially harder to explain code for each audience member added!)
What seemed so simple and direct privately quickly turns into a giant bowl of spaghetti that under pressure even you don't understand. Don't try to show production code (well factored and well partitioned), make simple inline examples that convey your core message.
My rule #1 could be construed, by the cynical, as don't overestimate you audience. As an optimist, I see it as don't overestimate your ability to explain your code!
rp
Since it sounds like you are doing a live presentation, where you will be working with real systems and not just charts (PPT, Impress, whatever) make sure it is all working just before you start. It never fails, if I don't try it just before I start talking, it doesn't work how I expected it to. Especially with demos. (I'm doing one on Tuesday so I can relate.)
The other thing that helps is simply to practice, practice, practice. Especially if you can do it in the exact environment you will be presenting in. That way you get a feel for where you need to be so as not to block the view for your listeners as well as any other technical gotchas there might be with regards to the room setup or systems.
This is something that was explained to me, and I think it is very useful. You may want to consider not going to slide heavy at the beginning. You want to show your listeners something (obviously probably not the code) up front that will keep them on the edge of their seats wanting to learn about how to do what you just showed them.
I've recently started to use Mind Mapping tools for presentations and found that it goes over very well.
http://en.wikipedia.org/wiki/Mind_map
Basically, I find people just zone out the second you start to go into details with a presentation. Conveying the information with a mind map (at least in my experience), provides a much easier way for the information to be conveyed and tied together.
The key is presenting the information in stages (ie, your high-level ideas first, then in more detail, one at a time). The mind-mapping tools basically let you expand your map, as the audience watches and your present more and more detailed information. Doing it this way lets your audience gradually absorb the data in smaller stages, which tends to aid retention.
Check out FreeMind for a free tool to play with. Mind Manager is a paid product, but is much more polished and fluent.
Keep your "visual representation" simple and standard.
If you're on Vista hide your desktop icons and use one of the default wallpapers. Keep your Visual Studio settings (especially toolbars) as standard and "out of the box" as possible. The more customizations you show in your environment the more likely people are going to focus on those rather than your content.
Keep the content on your slides as consisce as possible. Remember, you're speaking to (and in the best scenario, with) your audience so the slides should serve as discussion points. If you want to include more details, put them in the slide notes. This is especially good if you make the slide decks available afterwards.
If someone asks you a question and you don't know the answer, don't be afraid to say you don't know. It's always better than trying to guess at what you think the answer should be.
Also, if you are using Vista be sure to put it in "presentation mode". PowerPoint also has a similar mode, so be sure to use it as well - you have the slide show on one monitor (the projector) and a smaller view of the slide, plus notes and a timer on your laptop monitor.
Have you heard of Pecha-Kucha?
The idea behind Pecha Kucha is to keep
presentations concise, the interest
level up and to have many presenters
sharing their ideas within the course
of one night. Therefore the 20x20
Pecha Kucha format was created: each
presenter is allowed a slideshow of 20
images, each shown for 20 seconds.
This results in a total presentation
time of 6 minutes 40 seconds on a
stage before the next presenter is up
Now, i am not sure if that short duration could be ok for a product demonstration.
But you can try to get some nice ideas from the concept, such as to be concise and keep to the point, effective time, space management etc..
Besides some software like Mind Manager to show your architecture, you make find a screen recorder as a presentation tool to illustrate your technical task. DemoCreator would be something nice to make video of your onscreen activity. And you can add more callout to make the process easier to understand.
If you use slides at all, follow Guy Kawasaki's 10/20/30 rule:
No more than 10 slides
No more than 20 minutes spent on slides
No less than 30 point type on slides
-Adam