As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm going to make my monthly trip to the bookstore soon and I'm kind of interested in learning some user interface and/or design stuff - mostly web related, what are some good books I should look at? One that I've seen come up frequently in the past is Don't Make Me Think, which looks promising.
I'm aware of the fact that programmers often don't make great designers, and as such this is more of a potential hobby thing than a move to be a professional designer.
I'm also looking for any good web resources on this topic. I subscribed to Jakob Nielsen's Alertbox newsletter, for instance, although it seems to come only once a month or so.
Thanks!
Somewhat related questions:
https://stackoverflow.com/questions/75863/what-are-the-best-resources-for-designing-user-interfaces
User Interface Design
Don't Make Me Think is the one!
Also check out Steve Krug's website for tips and sample forms for usability testing.
The design of everyday things ? An "old" classic, but useful if you plan anything that requires human interaction.
Joel Spolsky's User Interface Design for Programmers is at least entertaining, and a recommended read.
Tufte, Visual Display of Quantitative Information http://www.edwardtufte.com/tufte/
Don Norman, Design of Everyday Things http://www.jnd.org/
Although completely independent of web and programming, The Design of Everyday Things by Donald Norman taught me a lot!
For a less in-depth, more cook-book approach (if you don't want to think), try Robin Williams' The Non-Designer's Design Book: Design and Typographic Principles for the Visual Novice.
Presonally I much prefer The Design of Everyday Things.
Also take a look at Alan Cooper's About Face.
The Apple Human Interface Guidlines are great!
This is not directly related to GUI design or programming, but The Psychology of Everyday Things is a good book to read.
It is a general look at how things are designed and how they fail. The concepts in this book, although not directly applicable to GUI's, do apply. In fact you could say they apply to all instances of user centered design.
http://www.amazon.com/Psychology-Everyday-Things-Donald-Norman/dp/0465067093
AboutFace.3.0
The Essentials of Interaction Design would be good Idea to read
"Don't Make Me Think" is great. After sitting in on several usability studies I can safely say that several of his biggest points are the kinds of things drilled in your head over and over.
Joel Spolsky's book on user interfaces is also decent.
http://www.amazon.com/User-Interface-Design-Programmers-Spolsky/dp/1893115941
Additionally to the great hints given so far, also see the Windows User Experience Interaction Guidelines, as described in this interesting blog post by Kirill Osenkov.
Related
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 4 years ago.
Improve this question
As a front-end developer, I would like to develop nice and good usability web applications. However, normally developers are good at coding. So, I would ask how to get started with learning some UI design knowledge? What's your recommended books or courses for a newbie to learn? Basically for graphic design, fonts and colors etc etc.
As a UI/UX developer myself, graphic design techniques are questions related to Photoshop, Illustrator, color theory, typography, etc. Usability is related to UI/UX, coding and web architecture. Graphic design and web usability are two very distinctive fields.
What is User Experience Design? - Wiki article on UX
User Experience is any aspect of a person's interaction with a given
IT system, including the interface, graphics, industrial design,
physical interaction, and the manual.
What is graphic Design? - Wiki article on Graphic Design
"Graphic design is the art of communication, stylizing, and
problem-solving through the use of type and image."
Resources #Nathan provided are great, I would also add this to your reading arsenal, education and inspiration:
Open University classes
University of Washington - Visualization
MIT - Drawings & Numbers
USQ - Multimedia
Berkeley - Computer Graphics
Sites & Inspirations
OnePageLove
Responsive.ly
A List Apart
Awwwards
Css Tricks
Tuts plus
Can I use
As with any other skill set, to way to get better is practice, practice, practice. I would just keep building projects as case studies and learn the skill sets as you venture through different types of web applications.
Best of luck on this journey.
Books are good, but to stay upfront and get aware of what is happening the latest and what tools and techniques are in, I suggest you to actively participate on webistes like
Smashing Magazine,
Sitepoint &
Web design Ledger
to name a few, but top quality resources. To know more about the books, you can refer to
Apress Books for front end development
for start to ninja resources.
Hope this helps.
Build on the shoulders of those who have gone before. To be a great developer, you have to know your stuff. In the same way, to be a good designer requires understanding of some basic foundational guidelines. Some of it may seem pretty simple and tedious, but understanding the proper principles of typography, color theory, grid systems and so on can help you a lot. A few resources to get you going are:
Universal Principles of Design
The Elements of Typographic Design by Robert Bringhurst
Thinking with Type by Ellen Lupton
Grid Systems: Principles of Organizing Type by Kimberly Elam
The Design of Everyday Things by Donald Norman
Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug
Microinteractions: Designing with Details by Dan Saffer
That list should generate it's own follow-on books / websites reading list for you.
Ask questions. Find some designers you really like and ask questions. Try to understand why they made the decisions they did. Most people are pretty willing to talk about their own work. Asking questions helps you to understand why designers use (or don't use) certain design principles in their work.
Actually design (and seek out constructive criticism.) Like anything you do in life, reading and learning can only take you so far. At some point, you have to start practicing. Find a small circle / community of more senior designers who can review your designers and give you some brutal, but constructive criticism. Your stuff will suck at first. Everyone's work does. Designers spend hours upon hours honing their talents and skills. Don't get discouraged by it. Just like anything you can gain mastery in, it takes time. Having people in your life who can give constructive feedback is a huge help.
Have a look at WebAwwards never let me down yet... Great selection and new websites added every day
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been advocating using Scala at my company. One of my co-workers forwarded me this link tonight
http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
I was hoping to get some constructive feedback from the SO community about this. I don't want this to turn into a flaming thread, but if there are legitimate concerns floating around out there I think it would be beneficial to discuss possible reasons and best practices that can avoid others falling into such traps.
I will say that I have been loving Scala and have not run into any of the problems that are mentioned. My application is also not very hashmap intensive, which appears to be where a fair number of their problems came from.
[Edit - apparently I need a question!]
The question is, do you think that the problems described are systemic to Scala, or more unique to their environment? If they are systemic, are there some good guidelines for a company that is just getting started with Scala to follow so that they don't end up in the same boat in 2 years?
Issues Described
Language Complexity
Systemic issue. Scala is unlikely to get less complex, whether or not that is a problem depends on the developers that are working with it. For me, it is complex enough to keep me interested and engaged, whereas pure Java can be mind-numbingly boring. My suspicion is that if Scala is way too complex for a particular developer, it is unlikely they're going to be top-notch dev when it comes to Java as well.
Community
So this one guy says the only way to do this is with a bijective map
on a semi-algebra, whatever the hell that is, and this other guy says
to use a library which doesn't have docs and didn't exist until last
week and that he wrote. The first guy and the second guy seem to hate
each other. What's the Scala way of sending an HTTP request to a
server?
That quote is pretty funny, but this is obviously a non-systemic issue with Scala. His main complaint about a lack of consensus regarding best-practices is relevant to all up-and-coming languages. I think Java developers have been spoiled in a way -- having gotten used to being part of such an enormous community where pretty much everything has been done before and possibly already standardized.
Build Toolchain
Another non-systemic issue.
Performance
This one does worry me a little bit and I can see getting frustrated very fast having to uncover previously unknown performance gotchas. I suspect for years to come there will be some pretty big performance penalties depending on how you use certain aspects of the language -- so people will have to exercise caution and make their own analysis regarding each project's performance requirements.
I concur with his sentiments here:
Despite the fact that we're moving away from Scala, I still think it's
one of the most interesting, innovative, and exciting languages I've
used...
And finally I would urge people to read Stephen Colebourne's blog with some degree of skepticism, because his personal disdain for the Scala language seems a bit oversize relative to the arguments.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Programmers often serves as a designer of user interfaces. You could argue whether it is good or not. However, especially in small companies, it is a reality that does not change.
What do you think personally as a programmer, is it our work to design UI? Personally I think that not, especially when you are going to work on Web Applications, where they made you to design UI also.
****Correct me if I am wrong.****
In an ideal world there should be a UI designer, just as there should be a DB designer, etc.
However, this would mean that even the shortest projects run by the smallest companies would need a team of at least 3 (or more) people. Because of the cost that this would incur it's never going to happen.
On small projects you are going to have to double up job functions in fewer people. It's a fact of life.
From a pragmatic point of view I think that all programmers should have an understanding of the basics of UI design, if only to be able to spot a bad one and do something about it. I also think that programmers should have an understanding of DB design as well.
You should look on this as an extra skill set you have which will give you more options when looking for new career opportunities in the future.
A GUI designer should design user interfaces. This is a different skill set. Of course, there's no reason why you shouldn't have someone in your team capable of performing both roles well, but it is important to recognise that the roles, and skills required, are different.
Should a programmer design User
Interfaces?
Only, If you're working in a small company or freelancer - one man army with limited team-size, where you often have to wear different hats of a programmer, tester, QC and the UI designer. This would not be the case for larger companies, where teams are large and responsibilities are divided horizontally or vertically.
Personally, I prefer working on projects where I have a view of the full application stack, so, for a web app, I'd hope to work on the UI, presentation, business and persistence layers.
I like to fully develop a 'feature', rather than a layer - it makes the work feel more real; but then I'd say that I'm probably not typical in that regard.
Also, I've found on projects where the work is divided by layers that there's (necessarily) a much bigger overhead in agreeing on the interfaces between different developers work. Arguably, of course, that's a good thing, because extra up-front design can only improve things, but I found that huge amounts of time were wasted with people waiting for others, and fixing thing that broke from a seemingly innocuous change.
Of course, there is a very different skill set, so you either need good all-rounders (who are probably less good at the minute detail of individual areas), or strong leaders for each technology. But I think the payback is fewer integration issues where everyone's code works perfectly, just not all together!
Some Web Application requires some good designs, you are right at that point. Thats because there are designers. For example, I am really bad at design. A programmer should have own Design Patterns on coding :). Of course, if you have a good idea on how to design, it should be good for you. You can both write & design your UI however you want. Be pro on coding, let designers design your UI :)
Good Luck
You have answered your own question i think, i have worked in companies where i would not be doing this and also companies where i would.
If you work on line of business apps the UI may not be a top priority and therefore a programmer is usually capable of this task.
I think a programmer can design UI well given the correct training. My university had UI classes, and there are short seminars / training classes out there today that hash over the basics of good UI Design. The important thing is to know your customer well, and the real use of your website - keep in mind that this may differ from your intended use. I.E. you may have intended one type of user to use your site in a very basic way, but it turns out it has become a favorite of expert users, so the UI needs to support that.
Often times your buying customer, if you are offering "solutions" rather than "products", will dictate large portions of the interface, right or wrong, so the affect of your design expertise is limited anyway. The important skill to have here is communicating the whys of your interface, and the why not's of theirs.
Programmers, generally, design horrible UIs.
I think the ideal here is a UI designer with some programming knowledge. While they will focus on the user's experience, they'll also know how certain UI decisions may have a big impact on the underlying implementation.
It depends. In a small company, of necessity programmers will also be designing UIs, so yes, it is your job. In a larger company, there may be others on the team whose job is to design the UI, so then no, it isn't your job.
The question here isn't "should programmers be responsible for designing UIs". In some jobs they will be, in others they won't. Some programmers enjoy designing UIs and are good at it, others don't. If you personally do not like designing UIs, then you should take jobs where you are responsible solely for writing code and not designing UIs. If you are currently in a job where you are being asked to design UIs and you don't want to do that, time to talk to your boss to see if there is someone else who could do that function. Say you don't feel UI design is a strength of yours and you want the company's product to be as good as possible, therefore is there someone else who could help design the UI? If there isn't, start looking for another job that better fits your skills and inclinations.
The team I work in is very small so we are all involved with the full software lifecycle, although we do have a dedicated QA team too.
Ideally not, but it's mostly better than the client designing the UI.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We user JIRA for bug tracking and release management and we have started using greenhopper for project management inside of JIRA but one thing that it lacks is the idea of user stories versus tasks in those users stories. Does anyone recommend other task board like agile project management tools that fully support users stories and tasks as well as being fast and simple to user. I started looking at targetprocess so if anyone has feedback on that specifically it would be great as well.
TargetProcess is the least intrusive project mgmt tool I've used.
A common anti-pattern for Scrum and XP teams is to break stories down into tasks, track those tasks, and at the end of the iteration notice that all tasks are done, but the user stories aren't (because they are more than just the sum of their tasks).
I highly recommend not tracking tasks at all. Brainstorm them for estimation, if you like, but always estimate and track whole stories. If a story is to big, break it down into smaller stories - that sometimes takes some creativity, but it's almost always possible.
You can use sub-issues in Jira to aggregate stories into bigger stories, although this isn't very well supported by greenhopper, as far as I remember. If your team is colocated, I would very highly recommend index cards on a white board, anyway - even additionally to Jira, if you have to (that's how we currently work).
Whiteboard and sticky notes or note cards.
I know you asked for software, but depending on your environment it might be hard to beat the communication value of a publicly visible task chart.
But if you must have software there's also Rally and VersionOne.
My company have been using TargetProcess for a while and we are very pleased with the product. Whenever we have experienced problems or bugs, we have reported it to them and the problem or bug is solved really fast. It's a great tool that worked well with SCRUM. I really recommend it.
Acunote is the best one I've found to-date. Really easy, simple and quick to use.
We use Jira with GreenHopper with no problems. If you have control over the configuration of your Jira instance, you can easily create a story issue type that allows having sub-tasks. During the planning phase, we drop the stories onto the next version, and split them into sub-tasks, estimated in more precise time and assigned to team members. If those tasks are separate you can also convert them into sub-tasks of a specific story.
Thoughtworks would be happy to sell you Mingle
Take a look at http://AgileZen.com/
take a look at jazz: http://www.theserverside.com/news/thread.tss?thread_id=44577, http://jazz.net/pub/index.jsp
We've just released a brand-new tool called Crew which might work for you. It's very flexible and allows you to set up a project structure and workflow that fits your process.
http://www.devmynd.com/crew
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was just listening to some older .Net Rocks! episodes, and I found #329 on DSLs to be interesting. My problem is that I can't find any good online resources for people trying to learn this technology. I get the basics of the creating new designers, but the MS docs on the T4 engine used by the DSL tools and then how to integrate the templates with the DSL models are lacking.
Does anyone know of some good introductory resources for the MS DSL tools?
The architects of the DSL Tools team wrote a book, Domain-Specific Development with Visual Studio DSL Tools. The book's website has some other links and resources.
If you are interested in DSLs, Jeff Moser has written some great articles about them (and the 'meta' frame of mind you need) here, here, and here on his blog.
Martin Fowler is currently writing a book on DSL. Here is a presentation he gave on the topic.
For me the best source of T4 examples was this blog.
Since you're looking to the MS-world, you may want to look at F#. It offers the ability to extend its syntax to write domain specific languages (see this link, page 16 for sample code).
I found the following page with a number of webcasts very usefull:
http://msdn.microsoft.com/en-us/vsx/cc677256.aspx
A fantastic option for DSLs is Boo. I've been using it for things like setting up my IoC container, defining routes, validation rules. Ayende Rahien is writing an fantastic book on the subject for Manning called Building Domain Specific Languages in Boo
PODCAST: DSL Related Discussions in SE-Radio
Martin Fowler is writing a book on DSLs. You can read his work so far here http://www.martinfowler.com/dslwip/
I also went to a good presentation by Jay Fields (His slides are here).
I would recommend http://msdn.microsoft.com/en-us/vsx/cc677256.aspx for DSL Tools as a starter.
Also, check out the concept of MDSD (Model Driven Development).
An expert on that topic (and DSL's) is Markus Voelter: http://www.voelter.de/
I believe there are so many similarities between MDSD, Software Production Lines and DSL's in general that this 'new' way of doing things needs to clean up it's concepts.
That's one of the reasons why it's hard to find good information about the topic.
On another note, acm.org has an extensive digital library of research articles, articles from various conferences (such as OOPSLA), where you can find much information about DSL's, language designs, SPL, MDSD, and so forth.
Here's a few more websites that I find useful:
Advanced code generation patterns
DslFactoryUtilities
DslTools
For the Visual Studio DSL Tools (tooling to add graphical DSLs to Visual Studio), there's an introductory hands on lab here: http://code.msdn.microsoft.com/Visualization-and-Modeling-313535db
The homepage for the tooling with links to other samples is here: http://archive.msdn.microsoft.com/vsvmsdk