Related
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.
This is a question I have had rattling around in my head for some time. I had a chat with a guy the other night who told me he would not be using the navigational framework because he could not figure out how it works with MVVM. As much as I tried to explain that patterns should be taken with a pinch of salt he would not listen.
My point is this, patterns are great when they solve some problem. Sometimes only part of the pattern solves a particular problem while the other parts of it cause different problems. The goal of any developer is to build a solid application using a combination of patterns know how and foresight.
I feel MVVM is becoming the one pattern to rule them all. As it is not directly supported by .Net some fancy business is needed to make it work. I feel that people are missing the point of the pattern, which is loosely coupled, testable code and instead jumping through hoops and missing out on great experiences trying to follow MVVM to the letter.
MVVM is great but I wish it came with a warning or disclaimer for newbies as my fear is people will shy away from silverlight development for fear of being smacked with the mvvm stick.
EDIT:
Can I just add as an edit, I use and agree with MVVM as a pattern I know when it is and isn't feasible in my projects. My issue is with the encompassing nature it is taking, as if it HAS to be used as part of development. It is being used as an integral feature and not a pattern, which it is.
EDIT 2: Thanks for all the comments so far, one issue that is surfacing from this is something I have not thought about until now. Is the introduction of richer more advanced frameworks for GUI/RIA development showing a weakness in RAD development for this generation. That is, is there a lack of code design and pattern knowledge being taught along with these frameworks? I once asked for a book on just C# (Before Pro C# & the .Net framework was popular) and was told why would I want to know C# minus winforms/asp.
Sure there are plenty of books/KB on these subjects but are people using them, beyond the superstars and very good programmers?
So, here's something that I think a lot of new MVVM developers forget - the pattern is there to help you, not the other way around. Building software in this manner tends to make your life easier as your project gets larger, but if it's completely getting in your way for a specific task, take a step back and ask, "In this specific scenario, is MVVM helping me here?" You're allowed to "cheat" a bit from time to time if it makes your life easier.
Actually I've used MVVM quite effectively with Navigation Applications with the Windows Phone 7 framework using commands and messaging. But if someone tells you that you can use every feature of Silverlight without adding some code to the code-behind, then they are fooling themselves. Use the pattern where it helps and make sense, and go "off-pattern" when a particular feature requires something custom.
Assuming your question applies to WPF as well, I sort of wonder if the problem isn't just the massive learning curve of WPF/Silverlight, before it even occurs to you to try out MVVM. Think about all the new things that need to be learned with WPF (and I assume Silverlight): XAML, dependency properties, attached properties, routed events, routed commands, static resources, dynamic resources, styles, data templates, control templates, databinding, etc., etc. etc. Then take the fact that Microsoft released this technology with an incomplete set of, at least with WPF, badly skinned controls, and you have a recipe for frustration and the inescapable feeling that you are dealing with a technology that is "not ready for prime time". I mean, before the WPF Toolkit came out, there wasn't even a proper DataGrid control.
Once you understand all these things, MVVM is yet another hurdle, but I don't think it's the main impediment to people jumping on the WPF/Silverlight bandwagon. That said, it would be nice if Microsoft would get behind it the way it has gotten behind ASP.NET MVC. As it stands today, you have to download and use third-party tools, like MVVM Foundation and MVVM Toolkit (which, incidentally, have a lot of overlap and should be combined into a single project).
So, I agree with you to a point, but I think most of the challenges involved with MVVM are probably due to the lack of support from Microsoft, and the inherent complexity of WPF/Silverlight, not due to any flaw in the MVVM pattern itself.
Great answers here, by the way. Good discussion and an important one to have. There is no doubt that learning Silverlight can be intimidating for new developers, and the MVVM framework will no doubt compound that.
However, I do agree that someone not understanding it isn't a dig against the framework. I still have developers who tell me that inversion of control/dependency injection is too confusing to learn, but does that make these invalid patterns? The fact the so much proven, "in the field" software relies on those concepts tells me they are sound even if complicated to grasp at first or understand.
Then again, learning a foreign was tough when I started, but once I pushed through, now I can speak it comfortable and wonder why it was so hard to begin with.
I guess the trend that scares me the most is this notion that for some reason complicated, enterprise applications should be easily built by beginner developers who either can't or won't grasp complex concepts. That's what it really boils down to. You don't have doctors saying, "Help, make this brain surgery easier so any one can do it." It's specialized. Building great software is also specialized, that's why consultants command good payment for their services: it's the value they provide in understanding the right way to architect and develop solutions.
If you are making an asteroids game, a fantasy game, a media site, a YouTube knock-off, etc, then you probably don't need MVVM and it is overkill. If you are building a small site with a few forms and graphs then build it how you are comfortable and be done with it.
If you are building a large, complex site that is composed of multiple, dynamic modules, moves thousands or millions of records and requires scaling to massive concurrent users, then you can't expect the design to just pop out after thumbing a few pages of a book or skimming a few sites. Software like that is complicated, with a lot of moving parts, and rqeuires a firm grasp of architecture.
What amazes me is people presumably building these more complex applications who still don't get building these more complex applications. Is there someone experienced on the team? Do you have an architect to stub out the framework that you can consume?
I mean really, the example just tells me the problem isn't MVVM, it's the developer. "Avoiding Navigation because of MVVM?" REALLY? What's MVVM got to do with it? Write the navigation pieces, and let the view models live inside the pages. Why does my navigation have to drive from a view model?
Come one. If it's that complicated I think it has nothing to do with the pattern, and everything to do with the developer just not understanding development. Don't blame the pattern. Maybe they need to stick to simpler applications. In my experience, people who come to understand the pattern understand software well enough that they know when and when not to use the pattern.
I know there are many movements to boil it down and make it simple for the "average consumer" but I think this is like trying to say, "Calculus is the wrong way to find the area under a curve because it's too tough to learn." While MVVM isn't as complex as Calculus, building complex software is a complex endeavor and I don't think you are ever going to simplify it or boil it down to a simple formula (nor should you). If you struggle with MVVM, please, don't use it - find something simpler and easier. If your project is complex enough to use it and you still don't grasp it, please hire someone who does, have them plumb it out and learn from them.
No, I don't want Microsoft telling me what pattern to use nor do I feel it is their responsibility. I'm a professional and it's on my shoulders to invest the time to learn and understand what I'm building so I can build it the best way for the customer. Microsoft doesn't necessarily know what my customer does or needs, so how can they possibly tell me what pattern to use? Projects like Prism are great because they are a compromise: they provide guidance and share "best practices" of how something can be done, without forcing that implementation on the developer.
I'm using MVVM for a Windows Phone 7 app. I really like the idea of it but there's too many hacks, wordarounds and 3rd party tools needed to get it running.
Things are getting better with every release of Silverlight but I still think the technology is "bleeding edge".
Why can't you?
And no, MVVM is just one of many patterns and frankly, not even amongst the most popular ones. What is hurting Silverlight's development is a) Flash b) not being Flash c) being Microsoft centric d) learning curve.
Plus the fact WPF doesn't really seem to have caught on doesn't much help.
Someone has problems figuring out how to use navigational framework with MVVM => Someone doesn't use navigational framework => MVVM is killing navigational framework => MVVM is killing Silverlight development.
Would you say there are few flaws with this chain of reasoning?
I'm going to write a rather big/complex WinForm application such as Paint.NET, SharpDevelop, etc. I think one of the most important things to build such an application is to structure the project properly to increase maintainability and control the complexity.
So what kind of patterns or practices show I use? Any blog posts, papers, open source projects are welcomed. I'm trying to learn something from SharpDevelop but it's rather huge for me to step into.
PS: I'm an experienced programmer formerly targeting to web developement(asp.net, rails, etc.). So I know some design principles and how to use them when implement business logics. Maybe I really need now is a sample to get started with a WinForm application so that I can realize how to handle the menus, controls and others. I've learnt something about the MVP pattern but still unconfident to start a large/complex application.
For big projects the methodology and the tools you are using are equally as important as the architectural design. You need to set up a source control system (like SVN) from day one. Also, it is very good to have a standard build procedure and perform builds in a daily basis. The build procedure should include running all tests, which you should also put some effort in implementing from the start.
Regarding the structure, I believe the single most important thing is to divide your project into building blocks with mimimal dependecies on each other. This way you will be able to think about one small part of the system at the same time and not have to face the full complexity of it. It will also help delegate some work to a fellow programmer, if you have this chance.
In order to get started, I recommend that you implement first something minimal as quick as possible. Then work to make it better and add functionality. This will keep you motivated as you will have something concrete to work with. It will also help you identify major design flaws and important issues early enough to correct them.
This is a good beginners guide from Microsoft itself:
http://msdn.microsoft.com/en-us/beginner/default.aspx
check the Windows track there.
After mastering basics - and since you are an experienced developer - you can check this book "patterns & practices Application Architecture Guide 2.0" from Microsoft also.
I would imagine that many of the techniques that make for successful web projects will translate to Winforms projects. Start small and grow the application incrementally. Try to keep the entire application building/working while you add features one at a time.
I'm planning to write my first program (it'll be in C#), and I need help with a decision. I know I'll want to use custom controls in the final version of the program (probably these), but someone advised me to use standard WinForm controls until the program is running right. They said once things are running right, then I could replace the UI with the custom controls I want. Is this the best way for me to do it? Or should I use the custom UI controls from the beginning?
About me:
-Never written a program
-Have some light Access/VBA experience and classroom C++ Logic and non-UI programming
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Thanks.
It depends on some factors:
The complexity: a simple custom-draw control can easily replace the standard winform control but generally custom controls add new features and tend to have differents methods and properties. In this case, switching to the custom control is not a simple task.
Your experience: Since you are pretty new to this, using a custom control can add another level of difficulty. Generally, these controls offers more options than the winform controls. So, it would be wise to start with the simple winform controls.
Since this is your first project, I tend to agree with your friend. While there is nothing inherently wrong with starting with third party controls, you will find that there is much more documentation and help available for the built in controls. In your early development efforts, you will likely hit many stumbling blocks, regardless of the choices that you make. Therefore, starting out with the most well-travelled course may make things easier for you starting out.
Once you have a little more experience debugging some of the issues that you will inevitably experience while learning a GUI framework, then it would make more sense to start bringing in glitzy third party controls.
Just use the standard controls. Keep it simple, Keep it simple, keep it simple. Also know that if you are still programming next year (hopefully on other projects), you will look back at this code in shame -- but that is a good thing.
Never written a program? I would not advise using any third party libs at this point, you are still learning. If you want the benefit of custom controls, why not write them yourself? You get the custom behavior and you actually learn how this stuff works.
Also, this statement is a bit of a red flag:
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Design patterns are great, but until you get some experience it is hard to understand why they are so great. Start like everyone else writing 'bad' code and then come back to the design patterns. That way you will truly realize why they are so important (rather than just being told that they are). Don't try to grok the advanced stuff before being full competent with the fundamentals.
Is delving into Microsoft's WPF worth it for a programmer who does not have design inclinations and no designer on the team?
I think so. The knowledge you take away from building simple screens/controls will help when creating custom controls for use across your app if/when a designer is hired. The real beauty is, if you're following MVVM with your WPF app, your UI can later on be more easily tweaked/replaced since the VM layer is already there handling the data behaviors.
I think a distinction should be made between design and user-experience. You can design a good GUI experience for the user with no creative flair or design inclination, just common sense and the ability to get feedback from users.
Ensuring a consistent interface, good flow and sensible cues are not design decisions in the arty sense of the word. It is like an architect making sure that the front door of a property is obvious ... and letting a designer pick the ornate decoration of the door. Art-design (color, pattern) is a creative design because many combinations work whereas GUI design is user-centric and so it has to work with their expectations which (unless designing a new application) tend to follow fixed convention, expectation and visual cues.
Any type of GUI experience is good for a programmer ... just as the API is the interface to the library the GUI is the interface to the user (the bit of the chain that counts).
Even though I don't design windows GUIs I make it a priority to sample good design in the area to stay ontop of user-expectations of software's capability in dry areas such as text-input. If users have grown to expect predictive input in most fields ... it helps to know when programming non-GUI elements.
Bit long-winded, but good reasons I think :)
I don't think WPF is all about designing with development. It's true that it does provide a great separation but it's not the only thing it does. It was great support of Data Binding which itself can save you tons of lines we repeat over and over again. Plus in order to make a good looking GUI, you don't really need great skills. I work with designer here and I don't think that I"m getting something big out that I coudln't do myself. But there are some really good designers as well. Also if you browser around some wpf apps, you'll get a good sense of how to design good wpf apps.
What are the characteristics of a good UI designer? How much does one have to have graphical design abilities these days as opposed to interaction design abilities. I see this of growing importance with the advent of WPF and Silverlight.
I personally consider myself good at interaction design, but would like to strengthen my skills in the graphical design area. Is it even possible to learn these skills or are you born with them? Can anybody recommend any good books or resources that would help?
Thanks,
Craig
Try the Non-designer's design book.
In my experience, interface design is a skill all in itself. Graphic designers are good at making wonderfully beautiful but completely confusing and unusable interfaces.
I have a few tricks I use but they mostly involve stealing design elements from well designed apps and websites.
In my experience, the hallmark of a good UI designer isn't necessarily a snazzy, do-it-all, isn't-that-cool solution, but generally one that's almost invisible because it just works with very little help from the user:
Controls and information are laid out logically, intuitively, and consistently.
The ease of accessing a feature is proportional to its frequency of use.
The user finds it almost impossible not to use the product correctly.
It breaks the "rules" when doing so increases its usability.
It's attractive in a "girl (or guy) next door" sort of way. Pleasant to look at, but not distracting.
I would look at any of the edward tufte books.
Jakob Nielson is a good author also.
Most people can look at user interfaces (like they look at anything graphical) and say "that looks good" or "that doesn't look good". What usually makes a graphics person able to produce good-looking material is a willingness to change and tweak things near-endlessly, and even throw out entire lines of effort, until something that looks good emerges. Most programmers do not have the patience for this kind of thing, so their user interfaces look like they were designed by someone who didn't much care what they looked like.
On a deeper level, the concept of "talent" or "innate ability" is most often used as an excuse not to even try something (e.g. "I'm not musically talented, so I'm not even going to try playing the piano"). If you want to become good at something, you have to practice it a lot - there is no alternative.
In my experience, it's a lot easier to find someone to make pretty pages, than someone who can do really amazing, subtle, non-obvious use cases. Use cases that aren't fundamentally table maintenance input forms.
If you're there already, I'd suggest you might think about finding a gui artist to pair-program with.
On the opposite side, if I find something laid out poorly, boxes that don't line up, awkward usage, poor grammar, I assume that the programmer is just as sloppy in their internal code. I expect more bugs in applications with a poor UI.
It's somewhat dated, but I enjoyed "The Design of Everyday Things". Good UI makes the user feel good without them ever noticing.
It is definitely possible to learn these skills.
What a lot of people get confused with is the difference between Art and Design. In many ways the difference between Art and Design is that Art has no understated functionality. It looks good...because it does. With Design there is usually a reason for something to exist. To be a good designer one must understand what good design is and how to efficiently break the boundaries of logic to create something that works with as little cognitive-load as possible. If a new UI design allows me to perform a task twice as fast as the old one then it is better. If I enjoy the experience of using the new one then it is better.
Of course, there is an artistic side to design, and by using flair and creativity a designer can make better designs.
If you want to become better at designing then there are two things you can do:
Read everything you possibly can about design. Find the best design Blog's and stick them in your RSS feed. Read through everything you possibly can about design.
Design something, then design it again, and again, then stop! Now, design something else...
Learn as much as you can about HCI. There are some great HCI books out there, even past the obvious choices. Read as many books as you can find.
Join a design community and monitor the work people produce. If you get the chance, collaborate with someone better than you and see how they tick.
I don't know enough about Art to say if you can learn how to become an artist. All I do know is that everyone is naturally creative; you just have to learn how to let it out in your work, that means learning how to use your tools effectively. Once you can do that then you can experiment.
I like to think that many of the standing HCI concepts we use today haven't just come from calculated thinking; more an artistic vision come to life.
it's all about the end-user's mental model - the abstract structure they form in their minds that leads them to just 'know' what to try as they explore your UI design. As a UI developer you need to clearly understand and then create that mental model for them - and a lotta times it will have nearly nothing to do with the composition of the underlying software system. So don't be surprised if some UIs are difficult to develop.
Once a user begins to visualize and embrace this mental model, they will start to explore and try things based on logically filling in the missing pieces. Good UI design will reward them with expected results, a bad UI will stymy and confuse and they'll wanna hunt you down.
Great UI means:
All the tools/data you see are actionable
That is, everything on the screen has meaning. If it doesn't have meaning or doesn't affect what you're going to do next, it shouldn't be there.
Understanding and using conventions
This is most of the time. Occasionally a great UI designer invents a new interface model (tags were invented to better handle photo-sharing).
Making everything frictionless
If you want to do something, you want to do it in as few steps as possible.
Making everything clean and understandable to the eye
You can't diminish the need for good UI design to at least be palatable to the eye. If you can't digest something visually in a very short amount of time, it might not be a good example of good UI.
About Face is a nice book too.
Subtlety is always something good to watch out. Harsh gradients and some color combinations are just a pain.
As a resource for designing user interfaces in Windows, I'd say that the Windows Vista User Experience Guidelines offers great tips and examples on designing user interfaces.
It provides both good and bad examples of user interfaces from actual Microsoft products, so I'd say it's actually quite objective and a valuable guide to use as a reference when learning about user interface design.
As it is designed as a guide for Windows Vista applications, it would fit in well with UI design for WPF, but the tips offered are general enough that they can also be applied to user interfaces that aren't Windows-based as well.
I'll add a pointer to a related question: Java User Interface Specification
Joel Spolsky's got a simple, elegant idea in the "Hallway Usability Test," as well as a series of posts on UI design.
I suppose the first book I'd suggest is 'the inmates are running the asylum". It takes a bit to get into, but it turns out to be a great book.
Online...
the w3's got some great ideas about how to design web pages.
The zen of palm coding should be required reading for gui design for pda designers.
This can be debated until the end of time, personally I believe that interaction design and graphical design are two quite separate things.
But both of them van be learnt, at least to a satisfactory level. You'll probably never be4come truly great at it unless you have a "talent" for it.
A book that I myself havn't read but I have heard many people recommend is "Don't make me think" by Steve Krug.
The sites I recommend for UI and design specifically are:
Alert Box, about web design, in particular. Good examples, use cases, and studies there.
Humanized, design principles. Check the blog too, specifically this and it's setup article.
Aza Raskin's Blog. He's part of Humanized (and now Mozilla), and his personal blog is a mine of insightful commentary on interface design.
The interesting thing about these sites is that they don't just give examples of UI "do's and don'ts", but back these examples up with specific metrics and methods that you can actually use to measure how "good" your UI is. Aza's blog is particularly interesting because he goes through his design iteration on several projects he's been part of, and talks about the "whys" for a lot of the UI decisions that were made.
Lots of links here to good guides, but the initial question remains: "What are the characteristics of a good UI designer?"
The ability to view a process, system or practice, and design an interface that makes the greatest improvement to it.
It's not about pretty interfaces, it's about what works best in that exact situation. And my advice for becoming a better user interface designer is to get better at putting yourself in the user position. We could all improve on that.
You can find a lot of designers who are able to draw pretty pictures, but the best have a working knowledge of interface design. Inherent in that is the ability to anticipate how a user will interact with an application without being prejudiced by the knowledge of how that application is supposed to work.
Regarding your second question - in my opinion, the programming model of WPF and Silverlight allows for a clearer separation between designer and coder (i.e. Microsoft Expression Design is for designers, .NET 3.5 is for coders, and Microsoft Epxression Blend is somewhere in the middle). That being said it is always better to have a UI designer who can handle both the design and the code.
And just to throw a book in there that I like - Luke Wroblewski's Web Form Design - you can get a PDF version of the book for under $20 bucks.