This is part three in a series. Parts 1 and Part 2 covered explorations of Office UI chrome. This article looks at what’s next.
As part of my work at Raizlabs I work with many companies that are creating new applications or updating existing applications. Over the past few years I’ve seen an interesting shift. Around 1998 most companies that had desktop applications began to flock to the web to create web-versions of their applications. Then in 2000 as the .com bubble popped many started building smart-client tools. This was usually in .Net, Java or even C++. Now I’m seeing a merging of these two worlds.
Rich client based applications are incorporating web UI (back/forward, links, breadcrumbs) and similarly web based applications are adding AJAX components to give users client side features: (right click, drag/drop, toolbars & menus.) The two worlds are merging and as far as the user is concerned it doesn’t matter if it’s web or windows.
From the development side I’m also seeing some interesting things as client side applications are embedding aspects of the browser within the application to perform either rendering or significant portions of the application. So to some extent the chrome of the browser is wrapped within an application. Although iTunes isn’t a web-browser many users experience the music purchasing process as if it was just a web-browser. Similarly Outlook uses a web-browser component to render the body of the HTML message and sometimes UI elements.
As the worlds of browsers and web-applications merge we will see two trends.
- There will be more web-browsers that are designed and released as special purpose applications
- You will see more functionality from a web-application that was previously only possible from a traditional application.
For the generic browser (Firefox & IE) this means that the tools and metaphors found within these browsers needs to be extensible as a model so that new applications that use the browser as a foundation don’t have to re-invent the wheel.
Both Firefox and IE release components to create applications (XULRunner and MSHTML) each of these packages the rendering components of the browser make it easy to re-use the rendering parts. Many companies are already doing this and there are already music players, contact managers, and large applications built using the web-browser interface from a client perspective.
From the web-side we will see the number of things that a web-site can do expand to encompass many of the things that are traditionally thought of as client tools. Adobe Flash has already been pushing this boundary and Java has been doing the same allowing web-developers to build more and more complete tools right within the browser.
The mix of client and server spaces means that it’ll be harder to tell where the data actually lives. A good example of this is Google Desktop. This application ties in neatly with the existing Google website functionality allowing you to search for things both on the desktop and on the web. The line is blurred and it’s not always clear when you’re within the web-space.
The same approach could be used by many other web-properties. Some examples:
- Flickr – upload photos and view photos in a seamless experience from desktop to web
- Plaxo/LinkedIn – synchronize with Outlook but keep the experience online
- Yahoo Maps – offline and online driving directions
- Etc Etc.
The traditional chrome of the browser will continue to add features and functions around HTML but at it’s core this framework will stay similar to what it has always been. The big Aha moment will happen when browser makers decide to focus on making it easy to create great applications and not just websites. Once this happens more people will realize that HTML, CSS and Javascript is an awful and imprecise way to develop software.
Up next. Why CSS Sucks…
Chris Moritz said…
*sigh
Jordi S. said…
And about this:
—
“If you can’t get the site to look exactly the way you want on every single browser then how can you claim that CSS is a good design tool or even a success?”
—
Ups, “to look exactly the way you want”? That is not what a web site is for. What about usability and accesibility? Users should be able to change font size; and they may have big or little screens; or … If you want control what users exactly see, give them a paper-sheet.
Greg Raiz said…
The problem is that it’s a an enormous pain with css.
I didn’t touch on accessibility but let’s call it a potential #11. People abuse css by turning lists into hover menus, fixing font-sizes so they don’t scale when the font increases and all sorts of other tricks that are totally not-accessible.
Jordi S. said…
well, I use Dreamweaver and let me tell that it’s not ‘great’ editing CSS. It’s probably better than any other editor, but there’s a lot of things that could be improved (although it’s a hard hard work).Sorry, I don’t exactly know what you mean by ‘high-end site’ (poor English, you see), but let’s take the model-for-ecommerce one: Amazon.
In Amazon users can change font size, the design ‘flows’ depending on screen-size, … Well, if you mean that designers want exactly “an usable design”, then I agree with you
But Amazon is not controlling design to the pixel (and they are doing right!).
Yes, you’re right: CSS may be wrong used against usability. But… it’s powerful, so it’s dangerous (as nuclear power is).
So I won’t say CSS sucks… No more than some tools suck, or some designers suck. CSS simply is not perfect
Ross Johnson said…
Every time I read posts such as this there always seems to be more of a “frusteration” than a good understanding and criticizm.
Your proposal to design a tool around the technology is a bit unrealistic. Shall we just convince all browser makers (including the ones that can’t even get CSS right) to just adopt a new technology?
Oh but wait, there is flash – and flash has it’s share of problems as well.
Once you get the hang of CSS it all makes sense and it is not frusterating anymore.
Mike G said…
Montoya said…
As a junior educator contributing to a college course with over 100 students learning CSS based design (as well as PHP programming), I can assure you that CSS is neither hard nor painful; if 100 students can learn it every year, and produce highly flexible, lightweight, and attractive designs with it, then maybe you just need to go back to school (and I say that without intending to offend you).
Greg Raiz said…
I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.
The fact that you are blaming me for not understanding is just funny. Your own portfolio proves my point:
html { font-size:100.01%; }
As a designer you shouldn’t have to fight the CSS and the browser to get what you want.
Montoya said…
html { font-size:100.01%; }
wouldn’t be necessary if it wasn’t for IE 6 being so common, but who do you blame that on? The W3C CSS group, or Microsoft? Mind you, it’s a bug in Microsoft’s software. Maybe that will help you shift the blame in the right direction.
You said: “I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.” Will your print design scale to the user’s window size? Will it allow the information to be used by multiple user agents (machines as well as humans, including humans who access the web in alternative ways rather than just visually)? Will it offer multiple styles? Will it be easy to modify in the future?
Or are we comparing apples and oranges?
The truth here is you don’t understand the web. You understand print design, and client side software, and even browsers, but that doesn’t give you any knowledge of how the web works. I still challenge you to really learn the medium, the technology, the research and the philosophy behind modern web design practices and why things work the way they do. If you did, you would understand why “problems” like cascading are actually features, and why this new way of looking at websites is a step ahead, not behind. Until then, you are entitled to your opinions, but you have no credibility to back them up.
Anonymous said…
Greg Raiz said…
Counter all 10 of my points if you want. Explain how a markup centric
language is better for design. Explain why consistency is not a problem. Explain why cascading is a good thing. Explain how things like CSS hover menus are a good for accessibility.
Go ahead and convince me. I’ll try to keep an open mind.
Scott said…
rebut your ten points on my own blog (not trying to spam; I felt it would get a bit long in the tooth to do it in your comments section).Mr. Montoya is corrent. You have a limited understanding of the medium. (Oh, and his website kicks ass.)
Greg Raiz said…
I believe CSS limits the creativity of designers by imposing technological constraints on visual designs. This may be because I come from a print background but that doesn’t change the fact that I still feel limited.
While CSS can be incrementally improved I personally think it’s important to think about how to make large improvements rather then incremental ones.
Michelle said…
Anonymous said…
Also, it is very easy to make your website look the same in all browsers.
Brett Mitchell said…
Of course, IE is and always will be the exception. While it is consistantly behind the other major browsers, support is slowly improving.
The point of the internet has evolved to be a source of information and entertainment that is widely available to everyone, everywhere – be it on a cell phone, by a visually impaired person with a braille keyboard, or your average citizen.
The internet isn’t a newspaper. You don’t have absolute control over what your viewers see. You seem to miss the point that the fact your viewers ultimately have control is the benefit of the internet – it’s customizable by individuals to meet their needs. If they need the font size larger, if they need to lower or raise the contrast, or they can’t see and they can have a browser speak to them.
CSS isn’t the be-all and end-all of design – you’re correct. If you want a design that aligns down to the pixel and has the perfect colours on every monitor/browser/platform, HTML is not your best bet to start with, and NO interactive language with the flexability of HTML could do that anyway.
HTML and CSS are easy to learn, cheap on bandwidth, viewable in every browser made in the last what, 6 years, including PDAs/cellphones…
What is your alternative?
Phillip Ryals said…
You push the idea that ‘something better’ should be created, either by fixing CSS or replacing it outright. I challenge you… how would YOU create this fictional superior method of describing a complicated design using RAW TEXT?
You see, from a designer /and/ programmer’s perpective, CSS is a very good tradeoff. No, I can’t draw a few boxes, apply some drop-shadows, scale some fonts, and see the results in a web browser. That’s life. Vector graphics for the web has been tried before in many many ways (anyone remember the Xcalibur BBS?) but it’s never taken off because it still requires more processing power than just rendering raw text.
The point is, you’re not going to get an easy-to-use method of creating complex designs. They’re complex, and so the method for creating them is complex. While CSS rendering isn’t predictable across all browsers (NOT the fault of CSS), it does indeed make many things possible that would otherwise never work.
Dean Hall said…
My rule of thumb is “Consistency, Consistency, Consistency” when it comes to a GUI. Neither CSS or anything else gives me an assurance of that. So I do what all developers do and I do whatever works. If CSS works for a project, then I use it. If it doesn’t look like it will, I use tables.
I thought this was a good article, with some valid points.
Anonymous said…
Anonymous said…
Anonymous said…
Most miss the point altogether, like:
Greg I just want to ask you what if I told you that Quark will no longer be supporting style sheets? Would you be ok with that? Even if you were working on a 120 page document? I’d be pissed, just like I would be pissed if they took away CSS.
This is irrelevant. Greg has not talked against the general idea of stylesheets, he talked against the CSS concept and implementation in particular. His points are specific and razor sharp, and could be used in designing a BETTER stylesheet language for the web. Like this point:
CSS captures styles not semantics or design intention. A design intention would be something like: “I want to balance these two columns” or perhaps “This text should line up with the logo image in the first column.” When designers do things like this:
#content{position:relative;top:32px;left:20%;width:40%;}They are capturing the style specifics not the design intention. Why 32 pixels? Why 40%? Perhaps the logo is 32px tall? Perhaps the other column is 60% wide? When the logo changes size or placement how will you know what styles to touch? There is a basic concept called parametric design that can be used to specify the parameters of the design.
Right on!
And since a lot of web pages nowadays are “web apps”, are you “css people” familiar with actual programming for GUIs? If you know GTK, QT, Java or what have you, they all have MULTIPLE layout models. CSS only has one, and a cripled one at that, the box model. A single model cannot solve all needs. (btw, almost all languages offer a table or grid layout manager, without sacrificing “fluidity”).
Some points:
a) The concept of styles is correct. It’s CSS that has it all wrong.
b) Design should be intention based and parametric. Hell, CSS does not even have parameters! If I want 20 design elements in my stylesheet to be 200px (or 20% or anything), I have to repeat myself 20 times over. When I want to change it to 200px it’s 20x times the work actually needed).
c) A lot of stuff should have been built in, in CSS and HTML and easier. Rounded corners? Blow me, just have something like:
#box {curve-top-right: 20px }
or have a way to define such effects in code blocks and share them.
etc…
Anonymous said…
Nick Presta said…
Oh, you mean like CSS3′s border radius property?
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius
Anders said…
Rich C said…
Web sites I build using CSS positioning for images are a lot more readable and maintainable than those I used to make using table-based layouts.
Greg Raiz said…
$logoh:120px;
$smallMargin:3px;
$largeMargin;10px;
.logo {height:logoh;}
.titletext {top:logoh+smallmargin;}
I’m using the $ show how you could declare a parameter/variable. This is still declarative so it’s not an ideal solution but at least it demonstrates how parameters could allow you to do things that are difficult or impossible to do via traditional cascading.
Anonymous said…
Or you can learn what cascading in CCS means and how to implement it.
Erm, cascading != parametric.
In the case I describe, for example, who told you that the 200px always refers to the same attribute (like width?). It could 200px of width for this element, 200px padding for the other, et al, used for implementing a consistent grid.
Or I could want a yellow background-color in one item, and a yellow foreground in some text or a yellow border in another. Cascading does not offer a way to define all these cases depending on a single color definition.
—
foljs
Daron said…
HTML, CSS, Javascript and all their evil offshoots are a result of:
* an inadequate and limited initial definition of the “web page” problem domain
* a crude, fatally flawed but simple to use initial technology (HTML)
* which lead to designers and programmers crufting up a mind boggling array of workarounds to fill the gaps (Tables and Spacer gifs)
* which spurred a belated attempt to redefine the underlying technologies by rigid academic edict mainly by non-designers (Cascading Style Sheets, XHTML, Widespread Deprecation)
* which was anyway largely undermined by the piecemeal and incompetent implementation of the new technologies in browsers and development tools (all of them)
* which is now all welded into place by the network effect, endless inert committees and monopolistic self interest. (Welcome to the Great Leap Backwards)
We are stuck with a kludge built on a kludge until we have a disruptive technology.
And Flash wasn’t it.
bjk2007 said…
Greg Raiz said…
bjk2007 said…
I did take the time to read it again after I had calmed down. I would have to say that while I disagree with you on several points, I do agree that CSS hasn’t done as well as it should have. Why? Simply browser support (IE). If we can’t get them to support CSS, how can we ever assume that they’ll support the newer and better theoretical CSS replacement language?
I guess the rest of my disagreements with you lie in a coder/designer mentality. You seem to be more of a designer while I’m actually a person whose strengths lie in coding, so we’re bound to disagree on how things should work.
Anonymous said…
IN PLAIN ENGLISH:
Not Microsoft, Netscape, Mac whatever can stop a standard being created, fact is those “browser companies” don’t make websites or web application (well they do make some) and developers NEED a standard so they aren’t writting 12 different lines to support 12 different venues. With these 2 standards (CSS2 and XHTML) we will have easier to maitain websites, portable applications, accessibility features for the blind/hearing impaired and about a million other applications.
SO TO ANY NEWBIE DO NOT LISTEN AND MAKE SURE TO USE CSS2 AND XHTML IN ALL FUTURE PROJECTS
Anonymous said…
josh said…
CSS is terrible. I’ve spent countless hours learning it and no matter what, the results are different from browser-to-browser.I can’t stand learning it, but at the same time I love the way some of these Css-driven sites are put together. I think to myself “I want that!” But it never happens. CSS is driving me insane. It always will drive me insane. Has potential, but it sucks.
John Nagle said…
CSS is, simply, a badly designed layout system. Even the rather simple system in Tk which lays out dialog boxes and windows is better. Tk is a nested-box system, but both “pack” (like CSS “float”) and “grid” (like tables) layouts are available in the same system. This is enough to handle most cases. Which “float” and “clear” are not. Page layout is forced to fall back on absolute positioning far too often.
The clever way to do layout would have been with a constraint system. Each box has four edges and four corners, and it would be possible to bind corners and edges to create any desired relationship between boxes. This is something one could express easily in a click and drag graphical tool. Want three columns the same height? Tie their adjacent bottom corners together.
Want to fill the page? Tie the outside corners to a page edge. Ten minutes to explain to an artist. Advanced use would involve priorities on constraints, so if something had to give in “fluid design” as the page size or type size changed, you could pick what gave first. (This could be extended to allow curved boundaries, even splines, but that might be overdoing it.)
The browser would have to have a constraint engine to resolve all the constraints, but there are known solutions to that problem.
Too many people drank the Kool-Aid on CSS. It’s just not that good a technology.
frostbyte said…
John Nagle said…
If CSS had a grid capability, it wouldn’t be so bad. But it doesn’t.
Anonymous said…
Anonymous said…
It was about separating format from markup to create data semantics.
Greg you are right on the nail. I wonder how many of these so called “CSS Designers” have the BIG profitable accounts.
Can you make the money with CSS on these sites using CSS, I dare you?
Look at these:
http://www.cosmopolitan.com/
http://www.elle.com/
http://www.nike.com
http://www.adidas.com
http://www.faithhill.com/
http://www.motley.com
http://www.imandd.com/index.html
Go on, make one of these (CNN for example) using CSS no hacks, js, pure w3c css. Publish the markup as a test and let us see that you know your css stuff.
Montoya you are the teacher, or is css only for the graphics blind? Prove Greg wrong, go ahead and make my day.
CSS can not do what the tables and flash can here. Forget semantics, forget standards, come and visit me for a little while in reality land. Bottom line people, hard cold cash it’s what matters.
Montoya get off you high horse and do something about it. Rewrite the standards so is more workable.
Use what works, and if you can separate format from markup with css and if tables have to be used so be it and format them in your css.