I had some trouble figuring out how to funnel users through different stages on a website I'm building and I figured that drawing a flowchart might help me see things clearer. So I started drawing a chart in Dia and an hour later I'd figured out what models and views I need to add and how to interconnect them. Given a little time, I can really see this kind of charting becoming a useful asset in my web development skill set.
One thing that bothered me though was the lack of symbols for common stuff related to web development. A symbol for forms would be nice. Maybe a way to indicate AJAX requests. I'm sure you can think of lots of other stuff. What are people using to visualise such things? Is there a standard set of symbols that I should use? I stumbled across UML years ago but never really got comfortable with it. Could that be used for charting web sites or is it not well suited to this task?
I use sequence diagrams to document the flow from page to page (including Ajax requests). Within a page, activity diagrams are often useful
For an excellent, short, and readable introduction to the use of UML, see UML Distilled
Another option: Jesse James Garrett's visual vocabulary for interaction architecture and design.
I don't use it personally, prefer using UML Activity/State diagrams. However a few UX designers I know are strong advocates. ymmv.
I don't beleive there are official standards but the shapes never seem to differ likewise. For an operation use a box. Start and end use an oval. For a decision use a diamond. The graphical ones aren't standard, but can still be used.
How easily will Watir interact with a ZK interface? If "not at all" do you have any recommendations for automated testing of the web interface for me?
Edit: Another way to put this would be can I test a Spring/ZK generated page (Ajax/JScript). I found another issue too: I need not to use a proxy to test (like Sahi does) if at all possible.
Edit: I have been testing ZK interfaces now for quite some time. With a higher knowledge of Watir (and now webdriver) I can say it's definitely possible. Timing isn't usually an issue, but finding the elements certainly can be as the ids are dynamically generated. I recommend a strong, maintainable, object oriented approach with a powerful and dynamic DSL, or you'll be listing every element on the page in a custom built object library of some sort. So... it works, but it needs extra effort.
If you're talking about this: http://zssdemo.zkoss.org/ you can take a look at the DOM output, it's atrocious, but possible to test it with Watir. I've dealt with some apps that generate awful output like that. It makes for a challenge. :) Search the Watir google group for testing Ajax, plenty of people do it.
HTH,
Charley
Is there a workaround for implementing cross cutting concerns without going into aspects and point cuts et al.?
We're in Spring MVC, and working on a business app where it's not feasible to go into AspectJ or Spring's aspect handling due to various reasons.
And some of our controllers have become heavily bloated (too heavily), with tons of out-of-focus code creeping in everywhere.
Everytime I sit down to refactor, I see the same things being done over and over again. Allow me to explain:
Everytime I have to prepare a view, I add a list of countries to it for the UI. (Object added to the ModelAndView). That list is pulled out of a DB into ehCache.
Now, initially it was terrible when I was trying to add the lists INLINE to the mav's everywhere. Instead, I prepared a function which would process every ModelAndView. How? well, with more garbage calls to the function!
And I bought out one trouble for another.
What's a design pattern/trick which can help me out a bit? I'm sick of calling functions to add things to my ModelAndView, and with over 3500 lines of only controller code, I'm going mad finding all the glue points where things have gone missing!
Suggestion are welcome. Cross cutting concerns flavor without AspectJ or Spring native.
Since you are using Java, you may consider moving your code to Scala, since it interacts well with Java, then you can use traits to get the functionality you want.
Unfortunately cross-cutting is a problem with OOP, so changing to functional programming may be a solution, but, I expect that in actuality they are using AOP to implement these mixins, so it would still be AOP, just abstracted out.
The other option is to look at redesigning your application, and make certain that you don't have duplicate code, but a major refactoring is very difficult and fraught with risk.
But, for example, you may end up with your ModelAndView calling several static utility classes to get the data it needs, or do ensure that the user has the correct role, for example.
You may want to look at a book, Refactoring to Patterns (http://www.industriallogic.com/xp/refactoring/) for some ideas.
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 9 years ago.
How can I make an Application look nice and not like an amateur pulled it together?
I mean graphic-wise.
Is there some sort of book you can read regarding beautiful program layouts, etc?
I put this in Community Wiki so please feel free to leave your opinions that way we can all learn. :D
Edit: Oh my god. I completely forgot to mention what kind of program. I mean desktop applications. Not web applications. :D
Find a graphic designer.
I'm not trying to be snarky, I'm just sayin'. I fancy myself a pretty good developer, but I am at stick-figure level when it comes to graphic design.
The skills (and the tools) for good graphic design are fundamentally different than the skills of a developer.
Three things:
Hire a designers that knows the business models and customers; unless you are good at it yourself
To help you provide meaningful feedback to the designer, read a book like
I like Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition by Steve Krug
Study many good Apps that have had success in the business of interest to you. Be inspired (aka copy) good ideas from them and mix in your own ideas. A prime example is how Google search "inspired" Microsoft's Bing
The following terms are really important when it comes to the look and feel of an application
User Interface Design
This talks about how the application has uniform soft colors, similarly sized controls, smooth fonts, appropriate groupings of data elements, etc.
User Experience
This is a much more difficult thing to attain. This is how intuitive the application is "Are you sure?" and "Are you Really sure?" message boxes, doing away with pop-up's and dialog boxes, auto-save, the flow from one stage to another, accuracy of data saves, and a host of other things that make the user experience truly amazing.
You cannot have good UX without good UI, but it is definitely possible to have a good UI without a good UX.
Just keep redoing it. Seriously, take all outside criticism. Ask them to be specific. If you're doing web work look at as many websites as you can. Sometimes, depending on the creator, you can email the website to ask why they did what they did and get a response. If you're doing desktop find a library you enjoy that can look good (not Swing, hate me if you want.) Then create, destroy, create, destroy, and so on until you're happy.
The biggest issue I think people have is learning to just throw away a component which isn't working for you.
I have found that going through the various desktop design guides can be pretty useful.
Windows User Experience Interaction Guidelines
Apple Human Interface Guidelines
Gnome Human Interface Guides
I don't think any of them can be considered as being "correct", but they will give you a good baseline idea as to what is expected in general as far as basic theory such as alignment, spacing and widget layout goes.
I recommend reading the AskTog site:
Bruce Tognazzini... ...founded the Apple Human Interface Group and acted as Apple's Human Interface Evangelist.
There's been some great stuff in the past, like how making buttons bigger is directly proportionate to their likelihood of being clicked, how mouse movement impacted design, etc.
But if you're not into learning - by all means, find a professional designer.
For Looks: Follow you platform's Human Interface Guidelines. Use the Golden Mean to please the eye. Simplify, Simplify, Simplify.
For Behavior: Watch the users use your application. Don't help them, don't correct them. Stand behind a two-way mirror if you can. You'll quickly find lots of places where your UI could use a tune-up.
I do try very hard to convince my users of the beauty of a command line interface.
Besides that, I think there is nothing better than "hallway testing". You can always hire an expert for GUI design though.
I really like the book Designing Interfaces. It presents many UI design patterns and when they are appropriate to use. It won't teach you how to make things "pretty", but it can help greatly in making your application intuitive and easy for a user to grasp. It also presents the patterns in a platform agnostic way.
There's lots of books out there are graphic design, interface design, web application design, css design, etc.
General rules:
think in terms of grids
don't fear white space
keep it simple
understand hierarchy
understand basic color theory
hire a user interface designer
Keep your coding work out of the design work, and do your mockups in photoshop or something similar before trying to implement them. Good coding and good visual UI design can be directly opposed to each other very often - what looks good on the outside takes some backend work that that most coders think is monstrous, and good UIs often require custom behavior where using standardized libraries might seem to make more sense from an engineering perspective. Having a target for the functional UI will help you to push yourself beyond the "good enough" results you might get if you let what your libraries do by default determine what the site or application will look like.
First of all, usability should always be priority #1 and should drive your design:
http://msdn.microsoft.com/en-us/library/ms997577.aspx
http://www.bucketsoft.com/blog/post/is-usability-standard-changing.aspx
However, that doesn't mean your application has to be ugly. And I disagree with those who say "you either have it or you don't." I think almost anyone can develop basic design skills if they put their mind to it. The very fact that you're asking about it proves that you're interested, which is a big step towards learning. And indeed even as a developer it helps to at least have a good sense for what looks good and how to make an engaging user interface. And if it's important you can always hire a professional designer later to take it to the next level.
There are a few fundamental details to design work that have helped me:
1.) Use colors wisely. Dull colors are not bad but they can make the design look boring and uninspired by themselves. If you add exciting, more saturated colors sparingly you can emphasize the more important elements. This will not only improve the look, but it can even be used to improve the usability by bringing attention to elements that you don't want your users to miss. Again, if you overdo this it's kind of like highlighting everything in your physics book. If you do it everywhere, it loses its meaning. I wrote more about colors and contrast in my answer here.
2.) Use white space wisely. This is huge. It doesn't matter if you're talking about a website or a Windows app -- a cluttered application is an ugly one. There is a good article about this relating to web design, but the same basic rules would apply to a desktop app.
3.) Fear not the big fonts. Another means for providing emphasis -- the big font. When combined with proper whitespace, a call-to-action written in great big words can be a powerful thing visually.
Come to think of it, all of these suggestions relate to creating emphasis.
There are a lot of sites that offer tips on Graphical User Interface (GUI) design. Google for "GUI design guidelines" and you'll find some. While these tips might not make your application look 'beautiful' they can make it look professionally designed. If you want beautiful graphics you might need to get some help from a graphic artist.
Check here for a good list of books on GUI design.
I really like this book, from Joel Spolsky:
[http://www.amazon.com/o/ASIN/B001O9LB86/ref=nosim/betteraddons-20]
General guidelines we use:
Make getting around easy: use a toolbar or side menu to access different parts of the application.
Make viewing information as easy as possible, and in different formats.
Make changing information as consistent as possible. I.e., put New, Edit, and Save buttons in the same place.
Make the most common action the easiest.
Specific guidelines we use:
Use the same or similar font across the application. Vary by size or bold to catch attention.
Use color backgrounds to group and separate types of information.
Put the most relevant information together and make the most commonly used button larger than the rest.
Don't use a drop-down control where there are only only a few options. Use a list control big enough that one doesn't have to scroll or use a radio-button.
Adding some white space can actually make it easier to read the screen or report.
Has anyone got any tips for the programmer who has no budget, or is working on a project at home for fun? We can't hire a designer, but we'd like to make a bit of an effort to get our applications looking less home-built.
I suggest showing a screenshot of your creation to family and friends. You'll hate their suggestions because they will differ from yours, of course. But it can help.
Research apps that are similar, AND some that are not, then pinch one small idea from each one!
Hire an expert. Design is something you either have or you don't. It sounds like you (just like me) are in the "don't" category :)
It'll give you an idea of where my head is at that my answer to "How do you normally make a program look beautiful?" starts with:
Short methods
Appropriate whitespace
Consistent naming conventions
Consistent formatting conventions
It's probably not a good idea to ask me what I think makes for a good UI.
I am trying to learn java web programming. I come from a perl scripting background and know very little Java, much less JSF/Seam/EJB3.0. I've made a LOT of progress in this very steep learning curve, but there are some large conceptual issues that I think are hampering me a bit.
Lately I've turned my attention to learning JSF. Usually discussions of JSF include a description of component-based web programming, but seem to assume one has experience with the other paradigms of web programming. I would be interested to see a fuller discussion of this component-based paradigm in the context of other paradigms.
Can someone explain?
Thanks in advance for your thoughts.
TDR
The basic idea is just an extension of Object Oriented Design: Separate the concerns of your program. The same way you may make several different PERL scripts and string them together to do work, we will make several different JSF components and string them together to do work.
Let's take a simple registration form as an example. I want to know your name, your birth date, your address and submit this all to the back end to do work.
First thing we need to do is break up your form into logical pieces. If we knew we were going to reuse this exact form in a lot of different places, maybe this form itself would be a logical piece. In which case we could create a component that would render this whole form and tie it to a bean like "Contact." That way, any time you needed to use the form, you could dump it in, tie it to a Contact bean (the how would depend on your framework) and go from there. But that would make this a pretty dull example. :)
From my estimation I see name, birth date and address as three seperate, logical units. Name would probably be simple. Just a standard text input. So we can use a h:inputText element, or your framework's prefered version, and tie that to your bean's name field.
Second, we have the birth date. At its simplest, we can create a h:inputText field and add a f:converter element so that when we tie it to the bean, it will come out a date. You can scale this up to be a fully interactive calendar widget, complete with Java Script and what not. Check out IceFaces and RichFaces for some good examples. But the same core concept remains: A single component which you will tie to a date object.
Third, we have the address. This makes a great choice for a component, because likely you will need to know addresses in a lot of different pages. It's also a lot more complex than a single input. You'll need to combine multiple inputs, validations and fun ajaxy stuff to make a single cohesive unit. However, the developer who uses it will hopefully only need to do use
<foo:address value="#{BarBean.address}"/>
with maybe a couple of other options.
This seperation of concerns is at the core of not only Component based web design but object oriented programming itself. There are plenty of tools to make this easier too! Facelets is a great example. You can seperate your basic layout into its own sheet, simply injecting the useful content via the ui:define elements. You can create composition components that allow you to quickly create more useful components without delving into the JSF component framework; the address example would be very simple to do with a Facelets composition component. IceFaces is another good example. It handles all sorts of AJAXy type inputs, redraws and updates without me having to worry about how it all works (for the most part. ;) letting me focus on what the form is to accomplish, not how to accomplish the form.
This only scratches the surface but the broadest strokes are similar to any large program: Identify the smallest, logical pieces and build them before using those to build bigger pieces.
I think that a good explanation would take a lot of effort. I'd suggest to get first your java skills straight, so you can understand the code examples that you'll encounter later when you try to follow tutorials from the web or even better buy a book.
In short:
JSF tries to give you the programming experience of a desktop application for a web based app.
Instead of having for example big JSPs you have lots of smaller components, that you can reuse.
The state of the page is preserved as much as possible even you do a real request (not just an ajax call) by transfering the state of the DOM components to and from the server.
JSF and Java EE in general is designed in such a way that large teams can split up the tasks into a more modular form.
Therefore, with components, instead of having multiple people working on the same .jsp or .xhtml page and the same Java backing bean class, components allow people to work on the same application without tripping over each other's feet.