Every once in a while I'll hear people say something along the lines of "well that's for web sites, but it's not really relevant for web apps." That implies there is some kind of line that separates the two. Different needs and rules that change the game and alter the conversation around them. Is it true?

The new poll up in the sidebar asks this question:

Is it useful to distinguish between "web apps" and "web sites"?

I'm asking in a very broad way. Is this a generally useful distinction to make that will help conversations and blog posts and conference talks and thus alter how we think and work on the web going forward? It's a boolean choice to make the results more clear:

• Yep. They are different things with different concerns.
• Nope. It's all just the web.

Food for Thought

A restaurant site that displays hours, the menu, and photos. That's a web site right? But what if you add an interactive map for directions. Is it a web app now? Or a web site with an embedded web app? What does it change? What if you could make reservations through the site?

Is the distinction as simple as "you log in to web apps"? What if you could log into a blog site, but the only reason you did that was to leave comments without having to type your name every time (and for spam protection). The site was otherwise just full of articles. Is that a site or app?

Is the distinction related to "you go there to browse" vs. "you go there to do stuff"?

Are sites all about content, while apps all about performing actions? What about a newspaper website with a paywall, customizable subscriptions, and re-arrangeable modules? Certainly a newspaper site is about content, so what does that make it?

Where do social media apps fall? How about sites where you build things? Online photo editors? Accounting apps? Bank software? Does "content" generally mean public content or can it refer to user generated or private content also?

Perhaps there are more practical differences to focus on. Perhaps sites have lots of navigation while apps have less. Perhaps sites need to assist more in search and discovery of content while apps less-so. Sites might need to consider things like Responsive Web Design more seriously, since it's open and the traffic could come from anywhere. Whereas on apps, it's more reasonable to ask someone to use specific software to get done what they need to.

Are sites "easier" than apps? Vice versa?

If there is a gray line, how thick is it? Is it still useful to know where you sit on that spectrum?

New Poll: Is There a Line Between Web Apps and Web Sites? is a post from CSS-Tricks

Read more about Rajashree's research here... 

Print’s a tricky business. Just because the dimensions are set in stone, we tend to think that everything will come out just the way we designed it. Oh, and it turns out the dimensions aren’t set in stone…

The reality is that print is as device dependent as screen-based design; in fact, possibly even more so. Sure, our proportions might vary wildly but at least an RGB color is always an RGB color (well, most of the time). When you’re dealing with print you have to deal with different paper stock, different inks, different printer technologies; there’s even the possibility that the job will be cropped in an unexpected way. Anyone but an expert can get into a mess pretty quick.

If you’re in a mess with print, or worried that you might be, this helpful infographic from UPrinting will get you on the right track.

Do you work with print regularly? What tips would you add? Let us know in the comments.

GatherContent: Simple Website Content Organization – only $24!

The aim of republishing the original article by Jake is to raise awareness and support the discussion about the role of progressive enhancement within the community. We look forward to your opinions and thoughts in the comment section. – Ed.

Progressive enhancement has become a bit of a hot topic recently, most recently with Tom Dale conclusively showing it to be a futile act, but only by misrepresenting what progressive enhancement is and what its benefits are.

You shouldn’t cater to those who have deliberately disabled JavaScript, unless of course you have a particular use case there, e.g. you’re likely to get significant numbers of users with the Tor Browser, which comes with JS disabled by default for security. If you do have that use case, progressive enhancement helps, but that’s not its main benefit.

You should use progressive enhancement for the reasons I covered a few weeks back. However, my article was called out on Twitter (the home of reasonable debate) as just “words on a page” and incompatible with “real-life production”.

Of course, the article is an opinion piece on best practice, but it’s based on real examples and actual browser behaviour. However, I wanted to find more tangible “real-world” evidence. Turns out I was staring at it.

I Love Tweetdeck

I don’t have Chrome open without a Tweetdeck tab. I use it many times a day, it’s my Twitter client of choice. It does, however, depend on JavaScript to render more than a loading screen.

Twitter used to be the same, but they started delivering initial content as HTML and enhancing from there to improve performance. So, they deliver similar data and cater for similar use cases, this makes them perfect for a real-world comparison.

The Test

To begin, I:

• Set up a Tweetdeck account with six columns,
• Closed all other apps (to avoid them fighting for bandwidth),
• Connected to an extremely fast wired network,
• Used the Network Link Conditioner to simulate a stable 2 Mbit ADSL connection and
• Cleared the browser cache.

I recorded Tweetdeck loading in a new tab, then cleared the browser cache again and recorded six Chrome windows loading the equivalent content on Twitter (here’s the launcher if you’re interested).

Now, 2 Mbit may sound slow, but I’ve stayed at many hotels where I’d have done dirty, dirty things for anything close to 2 Mbit. The maximum broadband in the area I live is 4 Mbit unless you can get fibre. On mobile, you’ll be on much lower speeds depending on signal type and strength.

The Results

Here are the two tests playing simultaneously (note: they were executed separately):

So Twitter gets the core content on the screen 7.91 seconds earlier than Tweetdeck, despite six windows fighting for resources. For the first bit of core content, Twitter gets it on screen 3.03 seconds sooner.

Twitter takes 4.09 seconds longer to finish loading completely, but this includes a lot of secondary content and heavy background imagery that Tweetdeck doesn’t initially show. On Twitter, the core content is prioritised.

That’s with an empty cache, but what about a full one? Here’s the same test, but ran a second time without emptying the browser cache:

So, with a full cache, Twitter beats Tweetdeck to all core content by 2.77 seconds, and first core content by 2.01 seconds.

Which test represents the “real-life” case? Well, something in between the two. As you browse the Web you’ll knock resources out of your cache, but also the site will cause cache misses through rapid deployments which change the URLs of resources. Current best practice is to combine and; minify your CSS/JS files and give them a unique URL, so whenever you need to make a change, no matter how small, the URL changes and the client has to download the new resource. Roll on HTTP2, I say.

Is This Test Fair?

Well, no. It’s real life, and as such it has the uncertainty of real life. But those are two expertly-built sites that offer similar content.

The test is unfair to Tweetdeck because:

• A lot of the XHR requests they make could be rolled into one, improving performance despite JS reliance (assuming this wouldn’t have large overhead on the server)

The test is unfair to Twitter because:

• Six separate requests are made for markup, whereas a true progressive competitor would use one. This incurs the HTTP overhead and repetition of common markup.
• It undergoes 6x the style calculations and layouts compared to Tweetdeck (because Twitter is running in six separate windows).
• I zoomed out all the Twitter windows so more content was visible, so the six windows have the paint overhead of scaling.

Of course, Tweetdeck gets away with it because it’s a tab I always have open, so I don’t go through the startup cost often. This is extremely rare for a website, even for those that claim to be “apps”.

You shouldn’t bet your performance on being a perma-tab. Twitter did this, but it turned out people shared and followed links to individual tweets and timelines, and the startup cost made them feel incredibly slow. They fixed this with progressive enhancement.

The Results Aren’t Surprising

Here’s what a progressively enhancing site needs to download to show content:

• some HTML
• CSS

…and those two download pretty much in parallel. The HTML will get a head start, because the browser needs to read the HTML to discover the CSS.

The whole of the CSS will block rendering to avoid FOUC, although if you want to put your foot to the floor you can inline the CSS for top-of-page content, then include your link[rel=stylesheet] just before the content that isn’t covered by the inlined CSS.

Rendering isn’t blocked by all your HTML, the browser can update the rendering as it receives more markup. This works with gzipped HTML too. Check out the full WHATWG spec (warning: it’s 2.6mb), although the markup is huge, it gets to first-render really quickly.

Ideally you’d have your script in the head of the page loading async, so it gets picked up by the parser early and enhances the page as soon as possible.

If a site does its content-building on the client based on API calls, such as Tweetdeck, here’s what it needs to download:

• All HTML (although small)
• CSS
• JavaScript
• JSON (API call)

The HTML, CSS and JavaScript will download pretty much in parallel, but the JSON download cannot start until the JavaScript has downloaded, because the JavaScript triggers the request.

The JavaScript on one of these pages can be significant, for instance Tweetdeck’s scripts total 263k gzipped. As Adam Sontag points out (using Mike Taylor as his medium), that’s the size of a few images we’d use on a page without thinking twice. But we would think twice if those images blocked core content from downloading and displaying, which is the case with the JavaScript on these sites. Hey, images even progressively render as they download, JavaScript can’t do anything until the whole file is there.

Getting something on screen as soon as possible really improves the user experience. So much so that Apple recommends giving iOS apps a static bitmap “Launch Image” that looks like the first screen of your app. It’s a basic form of progressive enhancement. Of course, we can’t do that on the Web, we can do better, we can show actually core content as soon as possible.

I’m open to examples to the contrary, but I don’t think a JS-rendered page can beat a progressively enhanced page to rendering core content, unless the latter is particularly broken or the content can be automatically generated on the client (and generating it is faster than downloading it).

I’m keen on the progressive enhancement debate continuing, but can we ditch the misrepresentation and focus on evidence?

© Jake Archibald for Smashing Magazine, 2013.

WebGL and CSS 3D transforms are two major technologies for creating 3D in the browser, and as recently as a few years ago, they didn’t have much browser support. Much has changed in a short period of time, and if you haven’t given 3D much attention (like me), you might have more catching up to do than you realize. The more recent versions of Internet Explorer support 3D transforms and the upcoming version (IE11) will support WebGL. My guess is that major browser support along with some kind of backlash to flat design could create the right conditions for 3D technology to flourish. Whether or not that happens, it’s a good idea to at least be familiarized with what’s already out there. The following is a high level summary of my research that should help get you started.

CSS 3D Transforms

The general sentiment behind 3D in the DOM makes sense. HTML describes structure and CSS 3D transforms describe visual presentation. As long as this relationship is respected, it’s a pretty logical path to walk. I’m not going to go into the details of 3D transform properties here, but you can learn more about them in the Treehouse course CSS Foundations. Instead, I’d rather give you a quick tour of some of my own exploits along with a few interesting projects you should watch.

Shading and Multiplaning

On the blog Codrops I wrote a guest article about a technique I call 3D shading with box-shadows. This is my most recent exploration into DOM-based 3D and I’m happy with it because it’s a bit more semantic than some of my other attempts. Previous to that, I posted on the Treehouse Blog about a technique I call multiplane design. The idea is that by adjusting the relative distances of flat 2D planes along the Z axis, you can create the illusion of 3D depth. Here’s a diagram from the post that should help explain: Even more recently, a JavaScript project called parallax.js implemented an idea with a similar spirit. Instead of multiplaning along the Z axis, they move their planes along the X and Y axes, which creates a wonderful illusion of deep space.

Modeling Objects

Around the same time, a 3D CSS editor called Tridiv was released. It behaves much like a traditional 3D modelling application on the desktop with several tools for manipulating objects and camera position. The resulting code can be pasted into your website quite easily, and they even allow you to edit the code on CodePen with the click of a button. For completeness, I’d like to mention that Tridiv utilizes a lighting engine called Photon, which is also an interesting project.

Creating Worlds

Finally, you should check out this amazing article from earlier this year called creating 3D worlds with HTML and CSS by Keith Clark. In the article, Keith describes some of the most advanced CSS 3D techniques I’ve ever seen. He even went so far as to write his own lighting engine and generate a height map for a player character to navigate multiple levels of terrain.

WebGL

The more advanced of the two technologies is WebGL. It has a much higher learning curve and can be difficult to grasp for beginners. If you’re new to 3D in the browser, I recommend you try using CSS 3D transforms first. Also, I found this talk from Steven Wittens at JSConfUS 2013 to be quite a good primer on 3D graphics:

Three.js

One of the most important projects in WebGL right now is three.js - it actually has renderers for canvas and SVG as well, but the WebGL renderer is great because it lowers the barrier to entry for WebGL. Three.js provides APIs for renderers, shaders, cameras, lighting, scenes, effects, and much more. There’s also a vibrant community creating demos and tutorials to help you get started.

Voodoo.js

Another one of my favorite projects is Voodoo.js because it allows you to overcome some of the shortcomings of using the canvas element. Using some clever code (that some might even call voodoo) you can mix WebGL contexts with normal HTML. Click through to the Voodoo website and then scroll down the page to see the cool parallax effects. You might also want to try highlighting the quote at the bottom of the page that has the golden ring around it. It’s just HTML text, but it magically has a WebGL ring floating around it. Pretty impressive.

chrome Experiments

If you’re still not impressed, you should definitely check out the WebGL Chrome Experiments. All of them are pretty amazing and you’ll get to see the range of what WebGL has to offer. One of the best I’ve seen is the Delight Engine demo which features some advanced real-time lighting effects I haven’t seen anywhere outside of top-tier AAA video game titles.

OK, so which 3D is the best 3D?

Recently, Acko.net got a WebGL redesign (this is the website of Steven Wittens, the guy in the JSConf talk embedded above). Steven talks about the redesign in an article called Zero to Sixty in One Second, and he said something that I can’t help but agree with:

…the DOM is not a good place to store complicated geometry.

I hate picking sides, and I really don’t want to take anything away from Tridiv, parallax.js, or even my own experiments in multiplaning. However, I don’t think it’s a good idea to muddle beautifully semantic HTML with elements that only exist to be polygonal faces. Maybe the CSS shapes module will change this somewhat, but right now you can only create rectangular faces. Some CSS hacks will get you a little further and allow you to create triangular and circular faces, but it’s still less than ideal. HTML is still decent for simple geometry, such as in my box-shadow shading example where each element has some sort of information inside. I just don’t think we should be building complex 3D models with div elements. Once a model reaches a certain level of non-semantic ugliness, it’s time to consider upgrading to WebGL. The limitations of WebGL can be overcome, and I think carefully weaving it into the DOM is a worthwhile pursuit. Voodoo.js does a great job of this and I only suspect this type of trend will continue. The redesign of Acko.net is another awesome example of how WebGL can coexist, unlike other technologies that are aliens in the browser (namely, Flash).

Designing with 3D

For some of you, the visual cool factor and technical wizardry isn’t enough. If you’re like me, you want to know what 3D can do in a practical setting. Right now, I’m really not sure what the future holds for 3D in the browser. Acko.net is a cool concept, but I don’t think it’s going to inspire everyone to run off and create their own 3D header. Will 3D be confined to the realm of games and demos? Does it belong within the context of building utilitarian web applications? Can such a label ever be applied, and does it matter?

The post 3D in the Browser: WebGL versus CSS 3D Transforms appeared first on Treehouse Blog.

UMBC Parents and Supporters -

As a service to our families here at UMBC, we are providing an online subscription to Student Health 101 for both your student and yourself. Student Health 101 is a monthly health and wellness magazine just for UMBC students and their families. Each issue contains valuable information that will help your student make better decisions and can help you gain a better understanding of the health and wellness challenges that face today’s students.

Each month, you’ll receive an e-mail with the latest issue of the family-only Parent Perspective, along with the Student Health 101 issue that your student will receive. Please take a few minutes to read the issues each month, as we believe that they can be a valuable resource for you and your family.

You can read the September issue of the Parent Perspective online at http://readsh101.com/umbc-pp.html .

You’re also invited to read the accompanying Student Health 101 issue for our students, online at http://readsh101.com/umbc.html .

The September issue has some great articles including:

- Get Up, Get Going: Quick breakfasts to fuel your day

- Bedtime Basics: How to establish your nightly routine

- What Would You Do?: How to step in and prevent sexual violence

- The Beginners Guide to Budgeting: How to manage your money one week at a time

- Chart Your Course: Using your syllabus to plan ahead

- UCookbook: Portable Snacks

- FitnessU: Exercise in Small Spaces

- And much more…

And if you missed it – be sure to check out the June issue, with Coffee, Copies, Fries with That?, Recharge and Refocus, How Do You Identify?, Free Yourself from Fast-Foodand more, at http://readsh101.com/last_umbc.html.

Thanks for taking the time to read Student Health 101!

UMBC University Health Services & Health Education

1000 Hilltop Circle, Erickson Hall, Baltimore, MD

(410) 455-2542

uhs@umbc.edu