Related
Can anyone point me to a useful guide for UI designers working in google web toolkit?
As per my comment to bhargava's answer, your designers should be learning UiBinder. The whole chapter about building user interfaces seems appropriate too (to get a better perspective), but UiBinder is what they will be mostly dealing with. Without using UiBinder in your project, you are stuck with Java and that's not something your designers are likely to know (and are probably not keen to :)).
I'd recommend building a simple example (but not too simple - maybe you should "strip" the official mail example) that uses UiBinder and show the designers exactly what you expect them to provide and what should be left as stubs. It all depends on the designers in question - whether all they know is HTML and CSS or maybe they have experience with Java, etc. Tailor the example to your needs - you probably won't "get it right" the first time, but with feedback from the designers (what's hard to understand, what they think should be the responsibility of the programmer, etc.), you should arrive at a good learning tool for future employees and a reference for current ones :)
Well if you're looking on how to use widgets and panels in gwt then i would recommend Roughian Examples
This website provides us the basic usage of the GWT widgets and panels and provides us with enough information just to get things started.
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 8 years ago.
Improve this question
It's well-known among teachers that some people can program and some can't. They just don't have mindset for that. In a nut-shell, I want to ask if the same is true about web-design.
I have a friend who is a good designer in general and can produce reasonably good-looking sites with WYSIWYG editor like Dreamweaver. But, since we're starting a common project, I'd like someone who can 'get hands dirty': work with html and css code directly. For many reasons, I'm sure you understand.
Now I'm thinking to incite him to learn, but not sure what're the chances of success.
So, do you also need some 'programming abilities' to profess css and html, or it's just a matter of training for regular designer?
I would especially like to hear particular experience from web designers.
PS I intentionally leave out JavaScript, let's keep it simple
The best web designers I have worked with know a small amount of html but don't use it when they are designing the sites. They do their work in PhotoShop (a minority will use GIMP). The reality is that I would rather they concentrate on laying out eye catching websites instead of trying to code it and lay the site out on the fly.
A web designer is absolutely not the same person as a front end web developer. That person has a skillset aimed towards converting the designers work into a set of working html/css templates.
Let me be clear that I am not saying that there is no cross-over between the two skillsets, but rather that very few people will be excellent at both design and development. If you are willing to settle for less than stellar results, at least be sure you go into the project with your eyes open.
Not at all. HTML is not a programming language, it's a markup language.
It shouldn't take you long to figure it out; I did it when I was 12. I personally think you need to be a better, how do I put it... artist to design websites than a programmer.
Of course websites nowadays are a lot more interactive, and for that you'll need some sort of server scripting (PHP, ASP, etc) and Javascript - and these are real programming languages.
A web designer who can't hand code HTML/CSS is not a web designer. The lack of such skills shows more of an aptitude problem(wanting to improve one's self). the graphic designer + front end developer combo doesn't always work well, because chances are the developer doesn't have the eye for the details in the design, such as margin, line-height, text kerning etc etc. Also it's hard to convert the interactive elements as well.
edit: this topic has been debated within the web design community on and off for a while now. You may find some interesting links in the blog post I wrote regarding this issue.
you are much better to know how to code a website HTML / CSS / Javascript before you go saying your amazing with a WYSIWYG editor. Sure you can use software to create a nice looking site but when it comes down to it how do you solve cross browser issues? How do you add dynamic content (even without server side) a WYSIWYG editor is just like designing a website in powerpoint or word but a lot more smarts. Though without the backing knowledge you are not going to go far.
As for learning plain HTML / CSS is fairly simple its an easy markup to get the understanding of. But then with that comes more, learning how to SEO plain HTML for example. There is always more to a site than HTML / CSS for it to be successfull.
This seems like a life question; I suspect it is true about almost anything. I think it can be hard to guage someone's aptitude for programming without seeing them actually try to program for awhile, however. Many people need to struggle with it for awhile before an "AHA!" moment is reached.
Nevertheless, I don't think design skills and abaility to work with CSS and HTML necessarily correlate to an aptitude for programming, per se. Of course, the two are not mutually exclusive,
It is not important for the designer to be able to program/markup/code in HTML or CSS. However, it is important for the designer to be aware of the current constraints imposed by HTML/CSS. With things becoming more dynamic, it is also important for the designer to understand how things are going to interact with each other. For example, you cannot become a real architect, without being aware of the constraints imposed by civil engineering.
But that's it. It is not important for a good designer to even know Dreamweaver or Photoshop or some other software :)
I am a university teacher, and I have also written both computer programs and HTML. Although I teach math, I understand the point about teaching computer programming. Although it might seem like there is no gray area between being able to program and not, I would say that writing in a markup language is one. You shouldn't divide the world into "cans" and "can'ts" with a question like this.
If he's a generally bright guy, yes you should encourage him to learn HTML and CSS. I wouldn't propagandize it as the thing that real men do or the greatest thing since sliced bread. Rather my argument would be to have a more complete perspective of what, after all, he's already been doing. Just as a racecar driver shouldn't necessarily need to pick up a wrench, but knowing what to do with one is useful for a deeper understanding. If you offer your friend a positive sell, the worst that can happen is that he'll say no and not take your advice. And who knows, he might even like it.
A lot of people either can't program or just wouldn't enjoy it, but don't mind writing in markup all that much. Most research mathematicians these days write their papers directly in a markup language, TeX/LaTeX, that in some ways looks a lot like HTML. Some mathematicians also like to write computer programs, but most of them don't. If they did like it, there is a good chance that they would have ended up in Silicon Valley. In fact in my profession, the whole question of can or can't write markup, or can or can't write programs, is stale. We're long used to a continuous range of abilities.
In my opinion, you can't have enough knowledge about this sort of stuff when doing any type of computer design or software implementation.
The more you know about the underlying technology, the better you will be at working with the high-level frameworks and constraints you live in.
Even if you work only in Photoshop in order to design a website, having the knowledge about what works and what will be more difficult in HTML/CSS/Whatever will give you an edge when designing that website over someone who doesn't know those details.
Of course, with knowledge comes constraints, which might be bad in and of themselves. Some of the best new technologies out there was built by people who didn't know that almost everyone else thought that what they tried to do was impossible.
But I still hold that more knowledge = Good Thing™
Web site creation especially a commercial website involves a LOT of different skill sets.
Back-end requires:
System Administration, Database Administration,
Web Applications development (anytime a website becomes interactive) requires server side programming skills and knowing various tools like (PHP, Java, ASP, Perl, C, C#, pick-flavour-of-the-month-server-side-language) and client side programming requires knowledge of browser behaviours mark-up languages and browser-side layout systems (HTML, javascript, CSS...)
Web Design requires artistic visual skills and related tools (Graphics programs)
Web Content requires language skills (Knowing how to proof read, translate, etc.).
Site Optimization requires knowledge of how to make sites appeal to various readers and audiences (both human and robotic)
A professional website involves several folks working in-tandem to bring all of the above together in various quantities.
If you are going to pursue something as a career, you need to know a bit about all aspects of that space and then follow in on what really excites you. So if someone is good at creating visually appealing content they should simply plan the content, and collaborate with someone to "program" their vision into the site.
Learning tools, and knowing about various components, is good as it tells you the boundaries and the playing field scope, but you don't need to know all of it to achieve professional competence in one specialization.
The Semantic Web is an awesome idea. And there are a lot of really cool things that have been done using the semantic web concept. But after all this time I am beginning to wonder if it is all just a pipe dream in the end. If we will ever truly succeed in making a fully semantic web, and if we are not going to be able to utilize semantic web to provide our users a deeper experience on the web is it worth spending the time and extra effort to ensure FULLY semantic web pages are created by myself or my team?
I know that semantic pages usually just turn out better (more from attention to detail than anything I would think), so I am not questioning attempting semantic page design, what I am currently mulling over, is dropping the review and revision process of making a partially semantic page, fully semantic in hopes of some return in the future.
On a practical level, some aspects of the semantic web are taking off:
1) Semantic markup helps search engines identify key content and improves keyword results.
2) Online identity is a growing concern, and semantic markup in links like rel='me' help to disambiguate these things. Autodiscovery of social connections is definitely upcoming. (Twitter uses XFN markup for all of your information and your friends, for example)
3) Google (and possibly others) are starting to pay attention to microformats like hCard and hCalendar to gather greater information about people and events going on. This feature is still on the "very new" list, but these microformats are useful examples of the semantic web.
It may take some time for it all to get there, but there are definite possible benefits. I wouldn't put a huge amount of effort into it these days, but its definitely worth keeping in mind when you're developing a site.
Yahoo and Google have both announced support for RDFa annotations in your HTML content. Check out Yahoo SearchMonkey and Google Rich Snippets. If you care about SEO and driving traffic to your site, these are good ways to get better search engine coverage today.
Additionally, the Common Tag vocabulary is an RDFa vocabulary for annotating and organizing your content using semantic tags. Yahoo and Google will make use of these annotations, and existing publishing platforms such as Drupal 7 are investigating adopting the Common Tag format.
I would say no.
The reason I would say this is that the current return for creating a fully semantic web page right now is practically zero. You will have to spend extra time and effort, and there is very little to show for it now.
Effort is not like investing, however, so doing it now has no practical advantage. If the semantic web does start to show potential, then you can always revisit it and tap into that potential later.
It should be friendly to search engines, but going further is not going to provide good ROI.
Furthermore, what are you selling? A lot of the purpose behind being semantic beyond being indexable is easier 3rd party integration and data mining (creating those ontologies). Are these desirable traits for your data sets? If you are selling advertisement, making it easier for others to pull in your content is probably not going to be helpful.
It's all about where you want to spend your time.
You shouldn't do anything without a requirement. Otherwise, how do you know if you've succeeded? Do you have a requirement for being semantic? How much? How do you measure success? How do you measure return on investment?
Don't do anything just because of fads, unless keeping up with fads is a requirement.
Let me ask you a question - would you live in a house or buy a car that wasn't built according to a spec?
"So is this 4x4 lumber, upheld with a steel T-Beam?"
"Nope...we managed to rig the foundation on on PVC Piping...pretty cool, huh."
Can anyone tell me some of the most important usability, accessibility and SEO guidelines, which must be taken into considerations while developing a good Web2.0 website ???
http://www.w3.org/WAI/
http://www.section508.gov/index.cfm?FuseAction=content&ID=12#Web
http://www.google.com/support/webmasters/bin/topic.py?topic=8522
Don't get too hung up on the "Web 2.0" buzzword. Accessibility standards have been around for a long time and are an important part of any web site.
SEO hint: Rewrite your dynamic URLs so that even the actual URL may be dynamic, it appears static. This allows spiders to fully index your site.
On Apache, you can do this by using mod_rewrite and there are symilar techniques for IIS.
Example:
Instead of
http://yourdomain.com/cgi-bin/getproduct.pl?id=12345
use something like
http://yourdomain.com/products/12345
As an alternative (or additional measure for those dynamic URLs you cannot rewrite), you should create a site map.
Incidentally, there was a recent article on it.
Other good Usability articles:
30 Usability Issues To Be Aware Of
12 Useful Techniques for Good UI Design in Web Applications
10 Useful Web Application Interface Techniques/
10 Usability Nightmares You should be Aware of
While I dislike the 'horror' tone of the article headlines, the articles themselves are good practice.
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 9 years ago.
Improve this question
I have a development process question.
Background: I work for a modest sized website where, historically, the designers created mockups/screenshots of what they wanted pages and components to look like, and the engineering team (myself included) turned them into html/css.
This works relatively well from a code cleanliness perspective, and helps significantly when it comes to writing javascript. It has fails, however, in helping to maintain consistency from one page/component to another. On one page, a header font might be 12px and on another 11px, largely because its a complicated site with lots to keep track of (and we've cycled through 4 designers.) We have only a few truly universal styles, and they only get used when the engineers recognizes the style - not when the designer tells them to.
Our most recent designer is a relatively capable HTML/CSS coder. We thought we might have him create mockups in HTML/CSS and hand us off the code for quick integration. Our hope was that the designer would be better at being consistent in his style and that it might save us some development time up front.
What we've discovered is that our designer is not quite as good as CSS as we had hoped and that his code is often slightly bloated and incompatible with what we need to do. Also, his style of coding is fundamentally different from the rest of the engineering team and isn't jiving terribly well with our established coding practices.
Question: How do you do the hand off from design to engineering? I know I've heard of companies that let their design team do all of the template coding, but I'm curious how that works. Does the design team actually incorporate members of the engineering team in those scenarios?
As we're structured right now, there's not a chance in hell we'd let our designer write the final templates and check them into SVN, even if he was a proficient HTML wiz. There's too much in the templates that requires knowledge of our codebase and of potential performance issues.
How do we get this process working? Is it a pipe dream?
Specifically - personally - since I come from a web-dev, small-shop background I do the CSS work and slicing the PSD (typically) myself. But then I like to think I'm well rounded like that :)
Generally, the best experience I've had of this was a largish company with very defined groups of developers including the design team who produced the gfx, the apps team who did the vast bulk of server-side coding and app architecture, and the UE (user experience) team who sewed the two together, producing XSLT/JSP/HTML markup in general, and the CSS and JS for the client-side.
There was a very structured process of:
userstory ->
"wireframe" (documents) ->
design (PSD) ->
"flat" markup (DHTML only) ->
integrated markup (with web-app)
Where "wireframe" would be close to a spec for UE, produced with UML or maybe visio. I have heard the term applied to step 4 which I think fits better, but this is what it was referred to as there.
Whilst this works well for the question at hand, I found it had other problems built in. It was very hard to work across teams, and because of the timescales the design team rarely involved UE in decision making (which put UE in some awkward positions), the apps team and design could be working at cross-purposes, and there wasn't a lot of scope to learn in these boxed in teams.
My suspicion (and I think ideal scenario) is that the developers on a project would each be capable of working with, say, 80% of the technology involved (be it CSS, SQL, whatever) to spread the decision control and risk, but each domain would have one (more?) "czar" who could act as authority and oversight within the domain. Actually producing those designs is to my mind a strange and magical skill in it's own right so I see no real overlap with developers there, but I think a pool of artists and project teams of cross-skilled programmers would be very powerful.
Apols for the long-windedness. I could go on at considerable length on this, I've spent a lot of time thinking about it.
btw, it seems like you could do with some serious web-devs there, (no offence). Having problems to "maintain consistency from one page/component to another" screams failure to grok CSS
In my experience, unless you limit your design severely, you need real coding skills to build a web page with interaction. Let me elaborate some. If you have built your pages very modular (think of GUI toolkit widgets) you can give your designer a handful of them, he can build the basic structure like playing toy blocks with a nice finishing paint.
Often, modularization alone is not enough for desired interactivity. So, some blocks needs their interactions to be designed carefully as well (like animation, fluid layout to accommodate indeterminate content, customized behaviour via extra javascript, caching to eliminate redundant requests and speeding up things) or ability to accommodate minor presentation variations, which brings us to the realm of programming, where you calculate dimensions, enable/disable parts, keep track of time, preload stuff, invalidate preloaded stuff and so on.
Enter HTML/CSS/JS. They are more of a product of evolution than intelligent design. You cannot always declare your intent and be done with it. You need attributes declared in your html, stupid hacks in CSS combined with extra markup, ridiculous amounts of js to smooth rough edges, duplicate rendering code on the server side. These tool were never meant to build applications.
I don't think one can achieve a complete separation of design and application development in these tools at hand. The effort required is too high to justify the marginal returns.
If you end up heavily modifying designer's code (which is othen the case if he is not one of the developers also), there is no point in making him suffer trying to express his intent using the wrong tools, nor developers breaking the design while modifying it and consequently fixing it. I don't even mention user experience.
In my opinion, no small internet businesses who want to ship a product in a reasonable time should spend their scarce resources to go against the grain. Let people do what they do best in collaboration if necessary. If you can't divide design process at an arbitrary satisfying point, you may as well not bother to separate at all. Pipelining works well for machines whose goal is determined to the last detail and not changing. I can't say the same for humans building and designing things be it software or hardware.
Where I work it's basically the same. Designers create mock-ups and specifications of the UI design, right down to the pixel, and the developer creates HTML/CSS/code out of that.
The reason I say code, is that we use UI frameworks (namely, GWT), and as much as we would want to, code and CSS styles are still very coupled. I do not believe there exists one UI framework in which code can be completely decoupled from the UI design.
So I guess for now it's still entirely the developers job. Though I would like to hear about organization which are able to hand off some of the work to designers.
The problem with handoffs is that the idea and implementation of one group is not going to match the abilities and implementation of the next group. Just by their nature handoffs are going to be wrought with problems. So what is an alternative to the ubiquitous handoff scenario? I think that integrating the user experience (UX) into an agile and iterative development process makes sure that what is really important occurs:
The customer's needs are researched then validated.
Early and continuous collaborating between usability experts, designers and programmers.
The actual process works by having everyone collaborate with the customer up-front on their needs. Then the design is researched and prototyped in the iteration before coding begins. Thus when coding is occurring, the next set of designs are being worked on. Programmers should be looking forward at what designers are doing and the designers look back to be sure programmers are on target. Once a design is coded, it goes to the customer for acceptance, by that time the programmers are working on the next set of interfaces.
Jeff Patton did a podcast on Agile UX recently that goes into some of the implementation concepts and common problems.
There is a whole group on Yahoo dedicated to agile usability (which mostly involves interface design).
For the CSS inconsistencies... I'd just suggest making a style guide then trying to stick to it. Have someone be in charge of "design consistency" that way the can spank anyone inventing yet another way to display the user.
At my company, my ideal work flow doesn't work very often, but sometimes it does. I löve when this happens: The engineers write the webapp and output semantic html with only minimal CSS. then you have the designers do the CSS.
I like it when it goes this way, because:
It is easy for me to write semantic
HTML.
I am not very good at coming up
with a good design for my semantic
html.
It is entirely possible to do
the CSS without asking me questions.
The markup just speaks for itself.
However, this rarely works. Because:
The CSS has to be modified whenever the HTML changes and the designers' time is sparse.
Moreover, our designers don't enjoy styling my markup, and fighting for their time is not pleasant.
Our designers often want to change the markup. Mostly because they believe some layouts cannot be done without changing the markup or because they believe that it's the only way to make IE obey. They are technically not able to change the markup, though.
I have my doubts about many of their cases. Many times they claim IE incompatibility, I strongly doubt they really know IE that well. There are neat CSS hacks to make IE obey without resorting to
<br clear="all">
So, sadly, usually this ideal is a little off for me.
A separate designer - developer workflow is the best way to go. Designing a website and coding it are altogether different jobs. There are issues of cross browser compatability, CSS, XHTML, apart from coding standards to deal with.
You could also opt for outsourcing your HTML to a specialized PSD to HTML conversion expert like us (ButterflyHTML). It may work out cost effective in the long run