"html" entries

Panels and panel sets

Common patterns emerge from a variety of components.

Distribution room power panel

Picture a modern web application. It almost certainly uses interactive controls, perhaps a carousel at the start, probably a set of tabs or an accordion, or maybe it is based on a coverflow or deck. These are common user interface metaphors: if you use these terms, designers know what you mean, and people recognize and know how to use them. At first glance these design patterns seem to have quite different characteristics, but we’d like to convince you that they really aren’t so different after all.

Ok, convince me!

The idea of a panel of content comes from the printing industry. In printing, a panel is a single page of a brochure, or one face of a folded leaflet. A print panel might be visually unique, like the cover of a leaflet, or be like other panels in a set, like the inner faces of the leaflet.

The concept of a panel has been applied to web design multiple times, generally becoming interactive along the way. Panels of content can be expanded or collapsed, removed completely, or presented in collections. Each of these design patterns has a common purpose: display a collection or set of things, generally one at a time to save on screen space. They may cycle vertically or horizontally, or peel off in layers, but these transition effects do not change the fundamental purpose of the thing – to navigate effectively through some pieces of content.

Read more…

Learning the Web

Finding a gentle entry to a big space

html5_fundamentals

The Web welcomes, but it’s awfully big. While HTML, CSS, and JavaScript may all be appropriate entry points for newcomers who want to create, finding a solid starting point can be complicated. Social media has minimized the level of HTML and Web knowledge people need to start contributing, but when it’s time to make the jump, the Web offers perhaps too many options.

Part of the challenge is that HTML, CSS, and JavaScript may be the marquee technologies, but they’re not actually what hosts a website or app. Setting up a site requires an additional set of technologies, from domain names to hosting to web server choices. Setting up a site – long before you get to packaging an app! – requires mastering an additional technical toolset and vocabulary that will help you navigate where you need to put your projects. Our free report, Getting Started with the Web, provides the core foundations beginners need.

Those aren’t the only barriers, though. Read more…

CSS fundamentally transforms

Enabling the creation of maintainable sites and apps that look great across a variety of different devices and contexts.

css_lp_620

Choose your Learning Path. Our new Learning Paths will help you get where you want to go, whether it’s learning a programming language, developing new skills, or getting started with something entirely new.

CSS is different. Cascading Style Sheets provide a text-based way to describe what web pages should look like, but it isn’t a programming language and it relies on HTML document structures as a foundation. You need to have a grasp of HTML before you start CSS, but CSS doesn’t look anything like HTML. Nor does it look like JavaScript, the most common programming language on the Web. Whatever your background, getting comfortable with CSS’ unique approach can take some work.

CSS’ declarative model can be uniquely efficient, but requires an understanding not only of the features you want to use but the approach you want to take in decorating a document tree. That means understanding the document tree (and there may be many variations as you apply the same style sheet to multiple documents), the selectors used to identify points on the tree, the cascade that resolves conflicts among selectors, and the properties applied to that tree. Of course, the properties interact with each other and a shared model, so you’ll need to understand how the properties how to make those interactions produce your vision.
Read more…

Abstraction in web apps: an idea, not an ideology

Create the Web instead of colonizing it.

Some weeks ago, when it was still wintry in one half of U.S.A. and anything but in the other half, I encountered the following Tweet:

The old man seemed lost and friendless. “I miss static HTML,” he said.

— Jeffrey Zeldman (@zeldman) March 12, 2015

I’m grateful to call Jeffrey Zeldman a friend, seeing as he’s a terrific guy in addition to being one of the foremost doyens of web design. In that sentiment and with the wish to call attention to his lament, I replied:

@zeldman Story of my last five years, that. When did simplification & removal of dependencies become subversive?

— Ben Henick (@bhenick) March 12, 2015

…And now I get to unpack all of that, as briefly as possible.

Read more…

Full-stack tensions on the Web

How much do you need to know?

Vista_de_la_Biblioteca_VasconcelosI expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.

In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.

Formal separation of concerns among HTML, CSS, and JavaScript made it easier to share responsibilities among specialists. As the dot-com boom proceeded, specialization accelerated, with dedicated designers, programmers, and sysadmins coming to the work. Perhaps there were too many titles.

Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
Read more…

How to build up to good CSS

Avoid problems associated with a quick fix by creating a stable workflow.

ice_curtain

A long time ago (circa 1999) a creative director tried very hard to convince me how great working in print design was compared to web design. One afternoon before a big event for a Fortune 100 company, she showed me an invitation her team had been working on for the past 2 weeks. It had folds, panels, and colors that would wow anyone. It had just come back from the printing press and she was excited to show me how amazing it was. She began reading me the big invitation title first — to her horror she found that there was a spelling mistake on the cover. The entire set of 10,000 invites would have to be thrown in the trash and at the cost of $15,000 — that would be hard mistake to swallow. She was speechless.

My response to what had just happened was this…”That’s why I like designing for the web. I would have been able to change that spelling mistake in 5 minutes…”

At that point in the web’s history anyone with a web connection, an FTP program and a text editor could edit HTML code on the fly. It really was the wild wild west of web development — this was the web’s best and worst attribute. For many young developers and designers it gave us a chance to create, edit, and publish web pages as fast as we could code them.

Read more…

It’s time for a web page diet

Site speed is essential to business success, yet many pages are getting bigger and slower.

Illustration of scaleEarlier this year, I was researching online consumer preferences for a client and discovered, somewhat unsurprisingly, that people expect web sites to be fast and responsive, particularly when they’re shopping. What did surprised me, however, were findings in Radware’s “State of the Union Report Spring 2014” (registration required) that showed web sites, on average, were becoming bigger in bytes and slower in response time every year. In fact, the average Alexa 1000 web page has grown from around 780KB and 86 resources in 2011 to more than 1.4MB and 99 resources by the time of the early “2014 State of the Union Winter Report.”

As an experiment, I measured the resources loaded for Amazon.com on my own computer: 2.6MB loaded with 252 requests!

This seemed so odd. Faster is more profitable, yet companies were actually building fatter and slower web sites. What was behind all these bytes? Had web development become so sophisticated that all the technology would bust the seams of the browser window? Read more…

What it really means when people say “Everything in JavaScript is an object”

A new mantra for your next (programming) meditation session.

When you begin programming with JavaScript you might run across books, tutorials, and people who say “Everything in JavaScript is an object.” While it’s not 100% true (not *everything* is an object), it is *mostly* true. And sometimes this can be a bit surprising.

For instance, to most people functions and objects look and act completely different. And in many languages, functions and objects *are* completely different. However, in JavaScript, a function is an object. This can take a bit of concentrated attention to get your head around, but it’s an important concept because it’s the secret behind another big topic in JavaScript: functions as first class values.

Read more…

It’s the end of the web as we knew it

You might feel fine.

For the past 15 years, Google has enforced the classic “HTML as foundation” architecture at the heart of the Web. Content creators and the developers who support them had to present content and link information as part of their pages’ HTML if they wanted Google’s spidering bots to see them. Google effectively punished developers who made links or content available only through JavaScript (or images, or CSS), giving them low or non-existent search results.

Google did this to keep their processing simple, not because of a deep fondness for HTML. Even as Google’s bots stuck to a simple diet of HTML, other parts of Google were developing JavaScript-centric approaches, like AngularJS: a “Superheroic JavaScript MVW Framework” that “is what HTML would have been, had it been designed for building web-apps.”

Angular is far from alone. As JavaScript grew, more and more programmers wanted to build their apps as programs, not as pages. Or, as Jen Simmons summarized it at Fluent, “Dang that stupid HTML, I’m just going to load an empty page… then I’ll run the real program, I’ll run the JavaScript.” Read more…

Dos and don’ts in JavaScript

A few best practices for when you're learning the language


With every programming language, there’s a list of do’s and don’ts and JavaScript is no exception. Some of these best practices are there for your protection (like always always always using semi-colons!); some to make your code more readable and less error-prone; and some to increase the efficiency of your code. Read more…