The Cleanest Trick for Autogrowing Textareas
Earlier this year I wrote a bit about autogrowing textareas and inputs. The idea was to make a more like a
Here’s the demo in case you just want a working example:
The trick is that you exactly replicate the content of the
in an element that can auto expand height, and match its sizing.
So you’ve got a , which cannot auto expand height.
Instead, you exactly replicate the look, content, and position of the element in another element. You hide the replica visually (might as well leave the one that’s technically-functional visible).
Now all three elements are tied to each other. Whichever of the children is tallest is will push the parent to that height, and the other child will follow. This means that the minimum height of the will become the “base” height, but if the replicated text element happens to grow taller, everything will grow taller with it.
So clever. I love it so much.
You need to make sure the replicated element is exactly the same
Same font, same padding, same margin, same border… everything. It’s an identical copy, just visually hidden with visibility: hidden;
. If it’s not exactly the same, everything won’t grow together exactly right.
We also need white-space: pre-wrap;
on the replicated text because that is how textareas behave.
This is the weirdest part
In my demo, I’m using ::after
for the replicated text. I’m not sure if that’s the best possible approach or not. It feels clean to me, but I wonder if using a
visibility: hidden;
is enough for that? Anyway, that’s not the weird part. This is the weird part:
content: attr(data-replicated-value) " ";
Because I am using a pseudo-element, that’s the line that takes the data
attribute off the element and renders the content to the page with that extra space (that’s the weird part). If you don’t do that, the end result feels “jumpy.” I can’t say I entirely understand it, but it seems like it respects the line break behavior across the textarea and text elements better.
If you don’t want to use a pseudo-element, hey, fine with me, just watch for the jumpy behavior.
Special high fives to Will Earp and Martin Tillmann who both randomly emailed on the same exact day to remind me how clever Shaw’s technique is. Here’s an example Martin made with Alpine.js and Tailwind that also ends up kinda like a one-liner (but note how it’s got the jumpy thing going on).
I’m sure ya’ll could imagine how to do this with Vue and React and whatnot in a way that can very easily maintain state across a textarea and another element. I’m not going to include examples here, partially because I’m lazy, but mostly because I think you should understand how this works. It will make you smarter and understand your site better.
The post The Cleanest Trick for Autogrowing Textareas appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
How to Design a Contact Page That Drives Engagement
How can your customer reach you? If a client arrives on your website after searching on Google, what can they do to take the next step in a relationship with your brand, without buying anything?
One of the primary aims of any website is to drive conversions. However, it usually takes between 5 and 8 touchpoints to generate a viable sales lead. People don’t want to convert straight away.
Since building a relationship with customers is crucial to success, it makes sense that the contact page would be an essential part of driving results. Unfortunately, a lot of website owners pay virtually no attention to that page. They ask their designer to create a page with their address and phone number on – and that’s it.
What many business owners don’t realize, is that the contact page is the door to deeper, more lucrative relationships with potential prospects. The design of this essential website element needs to be fantastic to drive results.
So, where do you start?
Defining a Well-Designed Contact Page
Let’s start with the basics, what makes a great contact page?
The complete answer to that question depends on the target audience. Some customers will want to see fun and friendly contact pages, complete with social media sharing buttons. Others will want to see a map that shows them exactly how to reach an office or business.
There are a few golden rules to keep in mind, of course. Contact pages should be:
- Easy to find: Don’t hide the link to the contact page on the website footer. Make it easy for customers to find out how they can get in touch.
- Simple: Don’t put too much content on this page or it will overwhelm your audience. Just let them know where they can go to get answers to various questions.
- Professional: Even if you have a friendly brand personality, your contact form still needs to be grammatically correct and well-designed to show a professional edge.
- Convenient: Make your phone number clickable so customers can use it on Skype. The same can apply for your email address. Provide easy access to social media profiles, and if you have a contact form – keep it short and sweet.
- Informative: Include all of your contact information in the same place. This may include your address, a map to your location, social media pages, email addresses, and even forums.
- Accurate: Ensure that the information on your contact page matches the information listed elsewhere. Check directories and Google my Business listings to be sure.
- Attractive: Yes, a contact page needs to look good too. Plenty of white space will make essential information stand out. A good layout will guide the eye through the page.
- Consistent: Make sure the contact form on your website matches the brand personality that appears on all of your other pages.
Take a look at the Tune Contact page:
It’s beautifully laid out, with clear information that’s easy to read. The company shows exactly why customers might want to get in touch and how they can reach out. As you scroll through the page, you’ll find additional office locations, email addresses for different teams (sales and support), and links to social media accounts too.
How to Drive Engagement on a Contact Us Page
A good contact page needs to look fantastic, showcase the company’s personality, and capture audience attention. However, there’s a big difference between a contact page that gets the job done, and one that convinces your audience they have to connect with you.
Here are some excellent ways to make your contact us page stand out.
Step 1: Using Color Correctly
Color and color psychology have a massive impact on user experience.
Studies constantly demonstrate the conversion powers of having the right shades on certain pages throughout your website. For instance, changing a CTA button from red to green can increase click-through rates by 27%.
However, every audience is different. The colors that drive engagement on a contact page for your company will depend on your target customer. A/B testing color palettes that match your brand personality is a good way to get started.
One interesting example of colors that make the right impact on a Contact Us page comes from Hubspot. Here, the brand maintains it’s brand color (orange), but it also introduces some new shades that convey trustworthiness and professionalism.
Blue is the most calming and credible color for any brand, The gradient that Hubspot uses here blends perfectly with its brand identity, allowing for a stunning contact page, with CTA buttons that still stand out.
Experiment with colors that can generate the right emotional response from your audience, but don’t ignore the golden rules of color in web design. You still need to showcase your brand identity, and you still need a way of making crucial information stand out.
Step 2: Humanizing the Customer Service Team
Some of the customers that arrive at a contact page are interested in your product or inspired by the potential of your service. Other customers will be looking for assistance because they’re frustrated with something or stressed out.
If you’ve ever had a problem with a product and wanted to reach out to the brand about it, you’ve probably noticed how annoying it is to find a blank contact page with nothing but an email address. The lack of effort and humanity in the contact page is enough to convince you that you probably won’t get a response.
But what if you add some happy smiling faces to the page?
Research indicates that brains are fine-tuned to recognize and appreciate human faces. Having a picture of your customer service team, or just any human being on your contact page makes you instantly more approachable. Your customers start to feel like they’re reaching out to a person – not an empty website.
Look at how engaging and personalized this contact page from Amber McCue looks:
Although you can show any human face on your contact page and potentially get results, showing your actual agents will be more likely to drive positive results. It’s a great way to showcase the authenticity and humanity of your team.
Step 3: Making it Easy to Find
A surprisingly large amount of the time, companies shove their contact information into the footer of their website, forcing customers to spend forever looking for them. However, your audience might not want to spend an age searching for your details if they’re in a hurry to get answers.
Stowing a contact page in a footer is also a problem for those visiting your website via mobile, as they might not be able to see all your footer details and links as well.
A Contact Us page doesn’t have to be a massive part of your website navigation if you don’t want it to be. However, it should be one of the first things your audience can see. Putting the information on the header of your website, or even sticking it to the top of the page as your users scroll is very helpful.
Zendesk makes it easy for customers to get in touch in multiple ways. First, the Contact section of the website is clear at the top of the page. Secondly, if you start scrolling through the Zendesk website, a “Get Help” button pops up, so you don’t have to scroll back to find assistance:
Remember, aside from making sure that your contact page appears in the right part of your website, it’s also worth ensuring that it’s easy to understand. Don’t use unusual terms like “Chat”, or “Chill with us”. Stick to tried-and-true options like Help, Contact, or Support.
Step 4: Making the Experience Relevant
There’s a reason why it’s practically impossible to find a one-size-fits-all contact page.
It’s because different customers need different things from your brand.
Some customers will be looking for the answer to a question; others will want to discuss something with your sales team. That’s why many companies are using adaptive contact pages that can change to suit the situation.
For instance, you may start by asking customers what they need help with. Zapier takes this approach with its Contact page:
By asking the client what they need straight away, Zapier can make sure that the visitor finds the right information, and the right number or email address for the appropriate agent. You can even scroll down the help page and look for something in the available help centre, using the search bar. Or you can click on View our experts to hire a Zapier pro.
Creating a dynamic and customized experience like this does a few things. First, it ensures that the customer will reach the right person to help them first-time around. This reduces the number of inappropriate calls your employees have to deal with, and the number of transfers.
Secondly, you deliver a better experience overall for your client, because they don’t have to repeat their issue to multiple people or start a massive email thread. They get the support they need immediately.
Dynamic contact pages can even save you some money and time. If clients decide to solve an issue themselves, using your resources, that’s great for your busy agents.
Step 5: Direct People to the Right Place
The central focus of your contact us page needs to be the available contact options. Centralizing the contact options on a page is an excellent way to make sure that they get the right amount of attention. Centralizing also means that your customers can spend less time searching for the contact details that they need, which is great for usability.
The Melonfree.com website uses a contact us form that’s centralized to immediately pull attention to the customer’s options for getting help.
Centralization isn’t the only way of using design principles to guide visitors on a contact page. According to Ray Hyman and Edmund Hick, increasing the number of choices on a page often increases the time it takes for people to make a decision.
When it comes to connecting with a brand, the right option for each customer will depend on the person and the situation they’re trying to overcome. For instance, a customer that needs to reset their password will probably be able to get the solution they need from an FAQ page.
On the other hand, someone who needs help using a new feature might need the guidance of a professional. To help guide customers to the right solution, Basecamp gives customers a variety of steps to follow to get the right solution fast.
The main purpose of the contact page is to help customers get the right answer with an informative form. However, there are unobtrusive alternative options available too. If all you’re looking for is a way to help yourself fix a problem, you can click on the help guides link before you ever scroll down to the form.
Step 6: Support the Contact Team Too
The best contact us pages aren’t just a great way to improve customer experience. Well-designed solutions also help the customer service team to save time and stay productive.
One of the primary metrics that companies consider when evaluating the success of a service team, is the number of replies required before an issue is resolved. However, if the initial question from a customer doesn’t contain enough information, this number often increases.
Using the design of the contact form to access the right information helps with:
- Automatically routing people to the right team member: Companies can set up segmentation rules that automatically send certain emails to different employees based on keywords. You might have questions that go to the sales team, and separate queries that you direct straight to the customer service team.
- Show appropriate support options and FAQs: Remember to give the audience a chance to help themselves before they reach out for extra support. Links to an FAQ page or self-service options can really reduce the pressure on a team. Some companies even add automated chatbots to the mix to help with self-service.
- Prompt for extra context: Although not every customer will take advantage of an opportunity to add extra information to a form, some will. Adding a box to your contact form for “anything we need to know?” is a great way to generate more information. Ban.do includes a simple “question” box where customers can add as much detail as they like. An option to add screen shots or documents might be a nice touch too.
Building Your Own Contact Us Page
Every customer has their own specific set of needs. The right contact page for another business might not be the right one for you. That’s why it’s so important to take some time getting to know your customers and speaking to your support team.
When you’re planning your contact page, it helps to ask yourself some basic questions about what you want to achieve. For instance:
- What kind of channels will our customers want to use to connect with us? Look at things like social media messaging, email, or phone calls. If you’ve got a relatively tech-savvy audience, then they might want to use things like instant messaging with chat bots too.
- How can we direct clients to the appropriate channels in as little time as possible? Having a system in place to automatically route your customers to the right agent will reduce the time to resolution for your customers. The faster you solve problems, the better your reputation becomes.
- What can we do to set customer expectations and build confidence before they speak to us? Designing a professional-looking contact page will increase customer confidence, while an FAQ section shows that you’re ready to answer common questions.
- How can we showcase a unique brand personality without making the page complicated? Everything from using distinct brand colors on a contact page, to adding images and illustrations reminds customers that they’re in the right place.
- What can we do to reduce the friction points in a customer’s path to contact? Avoid adding too many input options to a contact form and ensure that it’s easy to reach out when your clients have a problem.
Understanding exactly what your audience needs from you, and what they’re looking for when they come to your team for help reduces the effort involved for your client when they reach out for help. Remember, today’s digitally-savvy customers expect their interactions with companies to be as streamlined and simple as possible.
Make the Most of Your Contact Page
Contact pages are frequently an afterthought in the website design process. However, they’re one of the most valuable tools your company has. With a good contact page, you ensure that your customers can always reach you when they have problems. What’s more, you boost your chances of people wanting to reach out to the sales team too!
Good luck creating a contact page that encourages engagement from your target audience. Don’t forget to track your results from each design, and A/B test for optimization.
Understanding flex-grow, flex-shrink, and flex-basis
When you apply a CSS property to an element, there’s lots of things going on under the hood. For example, let’s say we have some HTML like this:
<div class="parent">
<div class="child">Child</div>
<div class="child">Child</div>
<div class="child">Child</div>
</div>
And then we write some CSS…
.parent {
display: flex;
}
These are technically not the only styles we’re applying when we write that one line of CSS above. In fact, a whole bunch of properties will be applied to the .child
elements here, as if we wrote these styles ourselves:
.child {
flex: 0 1 auto; /* Default flex value */
}
That’s weird! Why do these elements have these extra styles applied to them even though we didn’t write that code? Well, that’s because some properties have defaults that are then intended to be overridden by us. And if we don’t happen to know these styles are being applied when we’re writing CSS, then our layouts can get pretty darn confusing and tough to manage.
That flex
property above is what’s known as a shorthand CSS property. And really what this is doing is setting three separate CSS properties at the same time. So what we wrote above is the same as writing this:
.child {
flex-grow: 0;
flex-shrink: 1;
flex-basis: auto;
}
So, a shorthand property bundles up a bunch of different CSS properties to make it easier to write multiple properties at once, precisely like the background
property where we can write something like this:
body {
background: url(sweettexture.jpg) top center no-repeat fixed padding-box content-box red;
}
I try to avoid shorthand properties because they can get pretty confusing and I often tend to write the long hand versions just because my brain fails to parse long lines of property values. But it’s recommended to use the shorthand when it comes to flexbox, which is…weird… that is, until you understand that the flex
property is doing a lot of work and each of its sub-properties interact with the others.
Also, the default styles are a good thing because we don’t need to know what these flexbox properties are doing 90% of the time. For example, when I use flexbox, I tend to write something like this:
.parent {
display: flex;
justify-content: space-between;
}
I don’t even need to care about the child elements or what styles have been applied to them, and that’s great! In this case, we’re aligning the child items side-by-side and then spacing them equally between each other. Two lines of CSS gives you a lot of power here and that’s the neatest thing about flexbox and these inherited styles — you don’t have to understand all the complexity under the hood if you just want to do the same thing 90% of the time. It’s remarkably smart because all of that complexity is hidden out of view.
But what if we want to understand how flexbox — including the flex-grow
, flex-shrink
, and flex-basis
properties — actually work? And what cool things can we do with them?
Just go to the CSS-Tricks Almanac. Done!
Just kidding. Let’s start with a quick overview that’s a little bit simplified, and return to the default flex
properties that are applied to child elements:
.child {
flex: 0 1 auto;
}
These default styles are telling that child element how to stretch and expand. But whenever I see it being used or overridden, I find it helpful to think of these shorthand properties like this:
/* This is just how I think about the rule above in my head */
.child {
flex: [flex-grow] [flex-shrink] [flex-basis];
}
/* or... */
.child {
flex: [max] [min] [ideal size];
}
That first value is flex-grow
and it’s set to 0
because, by default, we don’t want our elements to expand at all (most of the time). Instead, we want every element to be dependent on the size of the content within it. Here’s an example:
.parent {
display: flex;
}
I’ve added the contenteditable
property to each .child
element above so you can click into it and type even more content. See how it responds? That’s the default behavior of a flexbox item: flex-grow
is set to 0
because we want the element to grow based on the content inside it.
But! If we were to change the default of the flex-grow
property from 0
to 1
, like this…
.child {
flex: 1 1 auto;
}
Then all the elements will grow to take up an equal portion of the .parent element:
This is exactly the same as writing…
.child {
flex-grow: 1;
}
…and ignoring the other values because those have been set by default anyway. I think this confused me for such a long time when I started working with flexible layouts. I would see code that would add just flex-grow
and wonder where the other styles are coming from. It was like an infuriating murder mystery that I just couldn’t figure out.
Now, if we wanted to make just one of these elements grow more than the others we’d just need to do the following:
.child-three {
flex: 3 1 auto;
}
/* or we could just write... */
.child-three {
flex-grow: 3;
}
Is this weird code to look at even a decade after flexbox landed in browsers? It certainly is for me. I need extra brain power to say, “Ah, max, min, ideal size,” when I’m reading the shorthand, but it does get easier over time. Anyway, in the example above, the first two child elements will take up proportionally the same amount of space but that third element will try to grow up to three times the space as the others.
Now this is where things get weird because this is all dependent on the content of the child elements. Even if we set flex-grow
to 3
, like we did in the example above and then add more content, the layout will do something odd and peculiar like this:
That second column is now taking up too much darn space! We’ll come back to this later, but for now, it’s just important to remember that the content of a flex item has an impact on how flex-grow
, flex-shrink
, and flex-basis
work together.
OK so now for flex-shrink
. Remember that’s the second value in the shorthand:
.child {
flex: 0 1 auto; /* flex-shrink = 1 */
}
flex-shrink
tells the browser what the minimum size of an element should be. The default value is 1
, which is saying, “Take up the same amount of space at all times.” However! If we were to set that value to 0
like this:
.child {
flex: 0 0 auto;
}
…then we’re telling this element not to shrink at all now. Stay the same size, you blasted element! is essentially what this CSS says, and that’s precisely what it’ll do. We’ll come back to this property in a bit once we look at the final value in this shorthand.
flex-basis
is the last value that’s added by default in the flex
shorthand, and it’s how we tell an element to stick to an ideal size. By default, it’s set to auto
which means, “Use my height or width.” So, when we set a parent element to display: flex
…
.parent {
display: flex;
}
.child {
flex: 0 1 auto;
}
We’ll get this by default in the browser:
Notice how all the elements are the width of their content by default? That’s because auto
is saying that the ideal size of our element is defined by its content. To make all the elements take up the full space of the parent we can set the child elements to width: 100%
, or we can set the flex-basis
to 100%
, or we can set flex-grow
to 1
.
Does that make sense? It’s weird, huh! It does when you think about it. Each of these shorthand values impact the other and that’s why it is recommended to write this shorthand in the first place rather than setting these values independently of one another.
OK, moving on. When we write something like this…
.child-three {
flex: 0 1 1000px;
}
What we’re telling the browser here is to set the flex-basis
to 1000px
or, “please, please, please just try and take up 1000px
of space.” If that’s not possible, then the element will take up that much space proportionally to the other elements.
You might notice that on smaller screens this third element is not actually a 1000px
! That’s because it’s really a suggestion. We still have flex-shrink
applied which is telling the element to shrink to the same size as the other elements.
Also, adding more content to the other children will still have an impact here:
Now, if we wanted to prevent this element from shrinking at all we could write something like this:
.child-three {
flex: 0 0 1000px;
}
Remember, flex-shrink
is the second value here and by setting it to 0 we’re saying, “Don’t shrink ever, you jerk.” And so it won’t. The element will even break out of the parent element because it’ll never get shorter than 1000px
wide:
Now all of this changes if we set flex-wrap
to the parent element:
.parent {
display: flex;
flex-wrap: wrap;
}
.child-three {
flex: 0 0 1000px;
}
We’ll see something like this:
This is because, by default, flex items will try to fit into one line but flex-wrap: wrap
will ignore that entirely. Now, if those flex items can’t fit in the same space, they’ll break onto a new line.
Anyway, this is just some of the ways in which flex
properties bump into each other and why it’s so gosh darn valuable to understand how these properties work under the hood. Each of these properties can affect the other, and if you don’t understand how one property works, then you sort of don’t understand how any of it works at all — which certainly confused me before I started digging into this!
But to summarize:
- Try to use the
flex
shorthand - Remember min, max, and ideal size when doing so
- Remember that the content of an element can impact how these values work together, too.
The post Understanding flex-grow, flex-shrink, and flex-basis appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
ARIA in CSS
Jeremey reacting to Sara’s tweet, about using [aria-*]
selectors instead of classes when the styling you are applying is directly related to the ARIA state.
… this is my preferred way of hooking up CSS and JavaScript interactions. Here’s [an] old CodePen where you can see it in action
Which is this classic matchup:
[aria-hidden='true'] {
display: none;
}
There are plenty of more opportunities. Take a tab design component:
Since these tabs (using Reach UI) are already applying proper ARIA states for things like which tab is active, they don’t even bother with class name manipulation. To style the active state, you select the with a data attribute and ARIA state like:
[data-reach-tab][aria-selected="true"] {
background: white;
}
The panels with the content? Those have an ARIA role, so are styled that way:
[role="tabpanel"] {
background: white;
}
ARIA is also matches up with variations sometimes, like…
[aria-orientation="vertical"] {
flex-direction: column;
}
If you’re like, wait, what’s ARIA? Heydon’s new show Webbed Briefs has a funny introduction to ARIA as the pilot episode.
Direct Link to Article — Permalink
The post ARIA in CSS appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
The Raven Technique: One Step Closer to Container Queries
For the millionth time: We need container queries in CSS! And guess what, it looks like we’re heading in that direction.
When building components for a website, you don’t always know how that component will be used. Maybe it will be render as wide as the browser window is. Maybe two of them will sit side by side. Maybe it will be in some narrow column. The width of it doesn’t always correlate with the width of the browser window.
It’s common to reach a point where having container based queries for the CSS of the component would be super handy. If you search around the web for solution to this, you’ll probably find several JavaScript-based solutions. But those come at a price: extra dependencies, styling that requires JavaScript, and polluted application logic and design logic.
I am a strong believer in separation of concerns, and layout is a CSS concern. For example, as nice of an API as IntersectionObserver
is, I want things like :in-viewport
in CSS! So I continued searching for a CSS-only solution and I came across Heydon Pickering’s The Flexbox Holy Albatross. It is a nice solution for columns, but I wanted more. There are some refinements of the original albatross (like The Unholy Albatross), but still, they are a little hacky and all that is happening is a rows-to-columns switch.
I still want more! I want to get closer to actual container queries! So, what does CSS have offer that I could tap into? I have a mathematical background, so functions like calc()
, min()
, max()
and clamp()
are things I like and understand.
Next step: build a container-query-like solution with them.
Table of contents:
- Why “Raven”?
- Math functions in CSS
- Step 1: Create configuration variables
- Step 2: Create indicator variables
- Step 3: Use indicator variables to select interval values
- Step 4: Use
min()
and an absurdly large integer to select arbitrary-length values - Step 5: Bringing it all together
- Anything else?
- What about heights?
- What about showing and hiding things?
- Takeaways
- Bonuses
- Final thoughts
Want to see what is possible before reading on? Here is a CodePen collection showing off what can be done with the ideas discussed in this article.
Why “Raven”?
This work is inspired by Heydon’s albatross, but the technique can do more tricks, so I picked a raven, since ravens are very clever birds.
Recap: Math functions in CSS
The calc()
function allows mathematical operations in CSS. As a bonus, one can combine units, so things like calc(100vw - 300px)
are possible.
The min()
and max()
functions take two or more arguments and return the smallest or biggest argument (respectively).
The clamp()
function is like a combination of min()
and max()
in a very useful way. The function clamp(a, x, b)
will return:
- a if x is smaller than a
- b if x is bigger than b and
- x if x is in between a and b
So it’s a bit like clamp(smallest, relative, largest)
. One may think of it as a shorthand for min(max(a,x),b)
. Here’s more info on all that if you’d like to read more.
We’re also going to use another CSS tool pretty heavily in this article: CSS custom properties. Those are the things like --color: red;
or --distance: 20px
. Variables, essentially. We’ll be using them to keep the CSS cleaner, like not repeating ourselves too much.
Let’s get started with this Raven Technique.
Step 1: Create configuration variables
Let’s create some CSS custom properties to set things up.
What is the base size we want our queries to be based on? Since we’re shooting for container query behavior, this would be 100%
— using 100vw
would make this behave like a media query, because that’s the width of the browser window, not the container!
--base_size: 100%;
Now we think about the breakpoints. Literally container widths where we want a break in order to apply new styles.
--breakpoint_wide: 1500px;
/* Wider than 1500px will be considered wide */
--breakpoint_medium: 800px;
/* From 801px to 1500px will be considered medium */
/* Smaller than or exact 800px will be small */
In the running example, we will use three intervals, but there is no limit with this technique.
Now let’s define some (CSS length) values we would like to be returned for the intervals defined by the breakpoints. These are literal values:
--length_4_small: calc((100% / 1) - 10px); /* Change to your needs */
--length_4_medium: calc((100% / 2) - 10px); /* Change to your needs */
--length_4_wide: calc((100% / 3) - 10px); /* Change to your needs */
This is the config. Let’s use it!
Step 2: Create indicator variables
We will create some indicator variables for the intervals. They act a bit like boolean values, but with a length unit (0px
and 1px
). If we clamp those lengths as minimum and maximum values, then they serve as a sort of “true” and “false” indicator.
So, if, and only if --base_size
is bigger than --breakpoint_wide
, we want a variable that’s 1px
. Otherwise, we want 0px
. This can be done with clamp()
:
--is_wide: clamp(0px,
var(--base_size) - var(--breakpoint_wide),
1px
);
If var(--base_size) - var(--breakpoint_wide)
is negative, then --base_size
is smaller than --breakpoint_wide
, so clamp()
will return 0px
in this case.
Conversely, if --base_size
is bigger than --breakpoint_wide
, the calculation will give a positive length, which is bigger than or equal to 1px
. That means clamp()
will return 1px
.
Bingo! We got an indicator variable for “wide.”
Let’s do this for the “medium” interval:
--is_medium: clamp(0px,
var(--base_size) - var(--breakpoint_medium),
1px
); /* DO NOT USE, SEE BELOW! */
This will give us 0px
for the small interval, but 1px
for the medium and the wide interval. What we want, however, is 0px
for the wide interval and 1px
for the medium interval exclusively.
We can solve this by subtracting --is_wide
value. In the wide interval, 1px - 1px
is 0px
; in the medium interval 1px - 0px
is 1px
; and for the small interval 0px - 0px
gives 0px
. Perfect.
So we get:
--is_medium: calc(
clamp(0px,
var(--base_size) - var(--breakpoint_medium),
1px)
- var(--is_wide)
);
See the idea? To calculate an indicator variable, use clamp()
with 0px
and 1px
as borders and the difference of --base_width
and --breakpoint_whatever
as the clamped value. Then subtract the sum of all indicators for bigger intervals. This logic produces the following for the smallest interval indicator:
--is_small: calc(
clamp(0px,
(var(--base_size) - 0px,
1px)
- (var(--is_medium) + var(--is_wide))
);
We can skip the clamp here because the breakpoint for small is 0px
and --base_size
is positive, so --base_size - 0px
is alway bigger than 1px
and clamp()
will always return 1px
. Therefore, the calculation of --is_small
can be simplified to:
--is_small: calc(1px - (var(--is_medium) + var(--is_wide)));
Step 3: Use indicator variables to select interval values
Now we need to go from these “indicator variables” to something useful. Let’s assume we’re working with a pixel-based layout. Don’t panic, we will handle other units later.
Here’s a question. What does this return?
calc(var(--is_small) * 100);
If --is_small
is 1px
, it will return 100px
and if --is_small
is 0px
, it will return 0px
.
How is this useful? See this:
calc(
(var(--is_small) * 100)
+
(var(--is_medium) * 200)
);
This will return 100px + 0px = 100px
in the small interval (where --is_small
is 1px
and --is_medium
is 0px
). In the medium interval (where --is_medium
is 1px
and --is_small
is 0px
), it will return 0px + 200px = 200px
.
Do you get the idea? See Roman Komarov’s article for a deeper look at what is going on here because it can be complex to grasp.
You multiply a pixel value (without a unit) by the corresponding indicator variable and sum up all these terms. So, for a pixel based layout, something like this is sufficient:
width: calc(
(var(--is_small) * 100)
+ (var(--is_medium) * 200)
+ (var(--is_wide) * 500)
);
But most of the time, we don’t want pixel-based values. We want concepts, like “full width” or “third width” or maybe even other units, like 2rem
, 65ch
, and the like. We’ll have to keep going here for those.
Step 4: Use min()
and an absurdly large integer to select arbitrary-length values
In the first step, we defined something like this instead of a static pixel value:
--length_4_medium: calc((100% / 2) - 10px);
How can we use them then? The min()
function to the rescue!
Let’s define one helper variable:
--very_big_int: 9999;
/* Pure, unitless number. Must be bigger than any length appearing elsewhere. */
Multiplying this value by an indicator variable gives either 0px
or 9999px
. How large this value should be depends on your browser. Chrome will take 999999
, but Firefox will not accept that high of a number, so 9999
is a value that will work in both. There are very few viewports larger than 9999px
around, so we should be OK.
What happens, then, when we min()
this with any value smaller than 9999px
but bigger than 0px
?
min(
var(--length_4_small),
var(--is_small) * var(--very_big_int)
);
If, and only if --is_small
is 0px
, it will return 0px
. If --is_small
is 1px
, the multiplication will return 9999px
(which is bigger than --length_4_small
), and min
will return: --length_4_small
.
This is how we can select any length (that is, smaller than 9999px
but bigger than 0px
) based on indicator variables.
If you deal with viewports larger than 9999px, then you’ll need to adjust the --very_big_int
variable. This is a bit ugly, but we can fix this the moment pure CSS can drop the unit on a value in order to get rid of the units at our indicator variables (and directly multiply it with any length). For now, this works.
We will now combine all the parts and make the Raven fly!
Step 5: Bringing it all together
We can now calculate our dynamic container-width-based, breakpoint-driven value like this:
--dyn_length: calc(
min(var(--is_wide) * var(--very_big_int), var(--length_4_wide))
+ min(var(--is_medium) * var(--very_big_int), var(--length_4_medium))
+ min(var(--is_small) * var(--very_big_int), var(--length_4_small))
);
Each line is a min()
from Step 4. All lines are added up like in Step 3, the indicator variables are from Step 2 and all is based on the configuration we did in Step 1 — they work all together in one big formula!
Want to try it out? Here is a is a Pen to play with (see the notes in the CSS).
This Pen uses no flexbox, no grid, no floats. Just some divs. This is to show that helpers are unnecessary in this kind of layout. But feel free to use the Raven with these layouts too as it will help you do more complex layouts.
Anything else?
So far, we’ve used fixed pixel values as our breakpoints, but maybe we want to change layout if the container is bigger or smaller than half of the viewport, minus 10px? No problem:
--breakpoint_wide: calc(50vw - 10px);
That just works! Other formulas work as well. To avoid strange behavior, we want to use something like:
--breakpoint_medium: min(var(--breakpoint_wide), 500px);
…to set a second breakpoint at 500px
width. The calculations in Step 2 depend on the fact that --breakpoint_wide
is not smaller than --breakpoint_medium
. Just keep your breakpoints in the right order: min()
and/or max()
are very useful here!
What about heights?
The evaluations of all the calculations are done lazily. That is, when assigning --dyn_length
to any property, the calculation will be based on whatever --base_size
evaluates to in this place. So setting a height will base the breakpoints on 100% height, if --base_size
is 100%
.
I have not (yet) found a way to set a height based on the width of a container. So, you can use padding-top
since 100%
evaluates to the width for padding.
What about showing and hiding things?
The simplest way to show and hide things the Raven way is to set the width to 100px
(or any other suitable width) at the appropriate indicator variable:
.show_if_small {
width: calc(var(--is_small) * 100);
}
.show_if_medium {
width: calc(var(--is_medium) * 100);
}
.show_if_wide {
width: calc(var(--is_wide) * 100);
}
You need to set:
overflow: hidden;
display: inline-block; /* to avoid ugly empty lines */
…or some other way to hide things within a box of width: 0px
. Completely hiding the box requires setting additional box model properties, including margin
, padding
and border-width
, to 0px
. The Raven can do this for some properties, but it’s just as effective to fix them to 0px
.
Another alternative is to use position: absolute;
and draw the element off-screen via left: calc(var(--is_???) * 9999);
.
Takeaways
We might not need JavaScript at all, even for container query behavior! Certainly, we’d hope that if we actually get container queries in the CSS syntax, it will be a lot easier to use and understand — but it’s also very cool that things are possible in CSS today.
While working on this, I developed some opinions about other things CSS could use:
- Container based units like
cw
andch
to set heights based on width. These units could be based on the root element of the current stacking context. - Some sort of “evaluate to value” function, to overcome problems with lazy evaluation. This would work great with a “strip unit” function that works at render time.
If we had that second one, it would allow us to set colors (in a clean way), borders, box-shadow
, flex-grow
, background-position
, z-index
, scale()
, and other things with the Raven.
Together with component-based units, setting child dimensions to the same aspect-ratio as the parent would even be possible. Dividing by a value with unit is not possible; otherwise --indicator / 1px
would work as “strip unit” for the Raven.
Bonus: Boolean logic
Indicator variables look like boolean values, right? The only difference is they have a “px” unit. What about the logical combination of those? Imagine things like “container is wider than half the screen” and “layout is in two-column mode.” CSS functions to the rescue again!
For the OR
operator, we can max()
over all of the indicators:
--a_OR_b: max( var(--indicator_a) , var(--indicator_b) );
For the NOT
operator, we can subtract the indicator from 1px
:
--NOT_a: calc(1px - var(--indicator_a));
Logic purists may stop here, since NOR(a,b) = NOT(OR(a,b))
is complete boolean algebra. But, hey, just for fun, here are some more:
AND
:
--a_AND_b: min(var(--indicator_a), var(--indicator_b));
This evaluates to 1px
if and only if both indicators are 1px
.
Note that min()
and max()
take more than two arguments. They still work as an AND
and OR
for (more than two) indicator variables.
XOR
:
--a_XOR_b: max(
var(--indicator_a) - var(--indicator_b),
var(--indicator_b) - var(--indicator_a)
);
If (and only if) both indicators have the same value, both differences are 0px
, and max()
will return this. If the indicators have different values, one term will give -1px
, the other will give 1px
. max()
returns 1px
in this case.
If anyone is interested in the case where two indicators are equal, use this:
--a_EQ_b: calc(1px -
max(
var(--indicator_a) - var(--indicator_b),
var(--indicator_b) - var(--indicator_a)
)
);
And yes, this is NOT(a XOR b)
. I was unable to find a “nicer” solution to this.
Equality may be interesting for CSS length variables in general, rather than just being used for indicator variables. By using clamp()
once again, this might help:
--a_EQUALS_b_general: calc(
1px -
clamp(0px,
max(
var(--var_a) - var(--var_b),
var(--var_b) - var(--var_a)
),
1px)
);
Remove the px
units to get general equality for unit-less variables (integers).
I think this is enough boolean logic for most layouts!
Bonus 2: Set the number of columns in a grid layout
Since the Raven is limited to return CSS length values, it is unable to directly choose the number of columns for a grid (since this is a value without a unit). But there is a way to make it work (assuming we declared the indicator variables like above):
--number_of_cols_4_wide: 4;
--number_of_cols_4_medium: 2;
--number_of_cols_4_small: 1;
--grid_gap: 0px;
--grid_columns_width_4_wide: calc(
(100% - (var(--number_of_cols_4_wide) - 1) * var(--grid_gap) ) / var(--number_of_cols_4_wide));
--grid_columns_width_4_medium: calc(
(100% - (var(--number_of_cols_4_medium) - 1) * var(--grid_gap) ) / var(--number_of_cols_4_medium));
--grid_columns_width_4_small: calc(
(100% - (var(--number_of_cols_4_small) - 1) * var(--grid_gap) ) / var(--number_of_cols_4_small));
--raven_grid_columns_width: calc( /* use the Raven to combine the values */
min(var(--is_wide) * var(--very_big_int),var(--grid_columns_width_4_wide))
+ min(var(--is_medium) * var(--very_big_int),var(--grid_columns_width_4_medium))
+ min(var(--is_small) * var(--very_big_int),var(--grid_columns_width_4_small))
);
And set your grid up with:
.grid_container{
display: grid;
grid-template-columns: repeat(auto-fit, var(--raven_grid_columns_width));
gap: var(--grid_gap)
};
How does this work?
- Define the number of columns we want for each interval (lines 1, 2, 3)
- Calculate the perfect width of the columns for each interval (lines 5, 6, 7).
What is happening here?
First, we calculate the available space for our columns. This is
100%
, minus the place the gaps will take. Forn
columns, there are(n-1)
gaps. This space is then divided by the number of columns we want. - Use the Raven to calculate the right column’s width for the actual
--base_size
.
In the grid container, this line:
grid-template-columns: repeat(auto-fit, var(--raven_grid_columns_width));
…then chooses the number of columns to fit the value the Raven provided (which will result in our --number_of_cols_4_???
variables from above).
The Raven may not be able give the number of columns directly, but it can give a length to make repeat
and autofit
calculate the number we want for us.
But auto-fit
with minmax()
does the same thing, right? No! The solution above will never give three columns (or five) and the number of columns does not need to increase with the width of the container. Try to set the following values in this Pen to see the Raven take full flight:
--number_of_cols_4_wide: 1;
--number_of_cols_4_medium: 2;
--number_of_cols_4_small: 4;
Bonus 3: Change the background-color
with a linear-gradient()
This one is a little more mind-bending. The Raven is all about length values, so how can we get a color out of these? Well, linear gradients deal with both. They define colors in certain areas defined by length values. Let’s go through that concept in more detail before getting to the code.
To work around the actual gradient part, it is a well known technique to double up a color stop, effectively making the gradient part happen within 0px
. Look at this code to see how this is done:
background-image:linear-gradient(
to right,
red 0%,
red 50%,
blue 50%,
blue 100%
);
This will color your background red on the left half, blue on the right. Note the first argument “to right.” This implies that percentage values are evaluated horizontally, from left to right.
Controlling the values of 50%
via Raven variables allows for shifting the color stop at will. And we can add more color stops. In the running example, we need three colors, resulting in two (doubled) inner color stops.
Adding some variables for color and color stops, this is what we get:
background-image: linear-gradient(
to right,
var(--color_small) 0px,
var(--color_small) var(--first_lgbreak_value),
var(--color_medium) var(--first_lgbreak_value),
var(--color_medium) var(--second_lgbreak_value),
var(--color_wide) var(--second_lgbreak_value),
var(--color_wide) 100%
);
But how do we calculate the values for --first_lgbreak_value
and --second_lgbreak_value
? Let’s see.
The first value controls where --color_small
is visible. On the small interval, it should be 100%
, and 0px
in the other intervals. We’ve seen how to do this with the raven. The second variable controls the visibility of --color_medium
. It should be 100%
for the small interval, 100%
for the medium interval, but 0px
for the wide interval. The corresponding indicator must be 1px
if the container width is in the small or the medium interval.
Since we can do boolean logic on indicators, it is:
max(--is_small, --is_medium)
…to get the right indicator. This gives:
--first_lgbreak_value: min(var(--is_small) * var(--very_big_int), 100%);
--second_lgbreak_value: min(
max(var(--is_small), var(--is_medium)) * var(--very_big_int), 100%);
Putting things together results in this CSS code to change the background-color
based on the width (the interval indicators are calculated like shown above):
--first_lgbreak_value: min(
var(--is_small) * var(--very_big_int), 100%);
--second_lgbreak_value: min(
max(var(--is_small), var(--is_medium)) * var(--very_big_int), 100%);
--color_wide: red;/* change to your needs*/
--color_medium: green;/* change to your needs*/
--color_small: lightblue;/* change to your needs*/
background-image: linear-gradient(
to right,
var(--color_small) 0px,
var(--color_small) var(--first_lgbreak_value),
var(--color_medium) var(--first_lgbreak_value),
var(--color_medium) var(--second_lgbreak_value),
var(--color_wide) var(--second_lgbreak_value),
var(--color_wide) 100%
);
Here’s a Pen to see that in action.
Bonus 4: Getting rid of nested variables
While working with the Raven, I came across a strange problem: There is a limit on the number of nested variables that can be used in calc()
. This can cause some problems when using too many breakpoints. As far as I understand, this limit is in place to prevent page blocking while calculating the styles and allow for faster circle-reference checks.
In my opinion, something like evaluate to value would be a great way to overcome this. Nevertheless, this limit can give you a headache when pushing the limits of CSS. Hopefully this problem will be tackled in the future.
There is a way to calculate the indicator variables for the Raven without the need of (deeply) nested variables. Let’s look at the original calculation for the --is_medium
value:
--is_medium:calc(
clamp(0px,
var(--base_size) - var(--breakpoint_medium),
1px)
- var(--is_wide)
);
The problem occurs with the subtraction of --is_wide
. This causes the CSS parser to paste in the definition of the complete formula of --is_wide
. The calculation of --is_small
has even more of these types of references. (The definition for --is_wide
will even be pasted twice since it is hidden within the definition of --is_medium
and is also used directly.)
Fortunately, there is a way to calculate indicators without referencing indicators for bigger breakpoints.
The indicator is true if, and only if, --base_size
is bigger than the lower breakpoint for the interval and smaller or equal than the higher breakpoint for the interval. This definition gives us the following code:
--is_medium:
min(
clamp(0px, var(--base_size) - var(--breakpoint_medium), 1px),
clamp(0px, 1px + var(--breakpoint_wide) - var(--base_size), 1px)
);
min()
is used as a logical AND operator- the first
clamp()
is “--base_size
is bigger than--breakpoint_medium
” - the second
clamp()
means “--base_size
is smaller or equal than--breakpoint_wide
.” - Adding
1px
switches from “smaller than” to “smaller or equal than.” This works, because we are dealing with whole (pixel) numbers (a <= b
meansa < (b+1)
for whole numbers).
The complete calculation of the indicator variables can be done this way:
--is_wide: clamp(0px, var(--base_size) - var(--breakpoint_wide), 1px);
--is_medium: min(clamp(0px, var(--base_size) - var(--breakpoint_medium), 1px),
clamp(0px, 1px + var(--breakpoint_wide) - var(--base_size), 1px)
);
--is_small: clamp(0px,1px + var(--breakpoint_medium) - var(--base_size), 1px);
The calculations for --is_wide
and --is_small
are simpler, because only one given breakpoint needs to be checked for each.
This works with all the things we’ve looked at so far. Here’s a Pen that combines examples.
Final thoughts
The Raven is not capable of all the things that a media query can do. But we don’t need it to do that, as we have media queries in CSS. It is fine to use them for the “big” design changes, like the position of a sidebar or a reconfiguration of a menu. Those things happen within the context of the full viewport (the size of the browser window).
But for components, media queries are kind of wrong, since we never know how components will be sized.
Heydon Pickering demonstrated this problem with this image:
I hope that the Raven helps you to overcome the problems of creating responsive layouts for components and pushes the limits of “what can be done with CSS” a little bit further.
By showing what is possible today, maybe “real” container queries can be done by adding some syntax sugar and some very small new functions (like cw
, ch
, “strip-unit” or “evaluate-to-pixels”). If there was a function in CSS that allows to rewrite “1px
” to a whitespace, and “0px
” to “initial
“, the Raven could be combined with the Custom Property Toggle Trick and change every CSS property, not just length values.
By avoiding JavaScript for this, your layouts will render faster because it’s not dependent on JavaScript downloading or running. It doesn’t even matter if JavaScript is disabled. These calculations will not block your main thread and your application logic isn’t cluttered with design logic.
Thanks to Chris, Andrés Galante, Cathy Dutton, Marko Ilic, and David Atanda for their great CSS-Tricks articles. They really helped me explore what can be done with the Raven.
The post The Raven Technique: One Step Closer to Container Queries appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Netlify Background Functions
As quickly as I can:
- AWS Lambda is great: it allows you to run server-side code without really running a server. This is what “serverless” largely means.
- Netlify Functions run on AWS Lambda and make them way easier to use. For example, you just chuck some scripts into a folder they deploy when you push to your main branch. Plus you get logs.
- Netlify Functions used to be limited to a 10-second execution time, even though Lambda’s can run 15 minutes.
- Now, you can run 15-minute functions on Netlify also, by appending
-background
to the filename likemy-function-background.js
. (You can write in Go also.) - This means you can do long-ish running tasks, like spin up a headless browser and scrape some data, process images to build into a PDF and email it, sync data across systems with batch API requests… or anything else that takes a lot longer than 10 seconds to do.
The post Netlify Background Functions appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Top 6 Tools For Creating an MVP (Designers’ Choice)
Top 6 Web App Builders Designers Choose to Create an MVP or an App Prototype in 2020
Whether you’re a mature product designer, or only starting your design career, regardless of your knowledge in web design, UI/UX, development, you can build and design a working prototype, or a minimum viable product (MVP) on your own. Today, it’s possible due to the existence of visual app builders.
We’ve compiled a list of the visual web app building platforms popular among UI/UX designers in 2020. Some of these app development & design tools are more feature-rich than others. Some lock you inside the platform, while the others allow you to download your app code, and go your own way. Consider all the factors when choosing your perfect match.
Let’s now look at the app makers designers choose to build & design MVPs and prototypes – clear, simple, viable enough to show the real value, created at minimal costs, and with almost no development skills (like you can do in Webflow, for example).
#1. Bubble.io
Bubble is a full-stack app development platform allowing you to create and design pixel-perfect web apps. You can build social network apps, SaaS, marketplaces, and more.
Pros:
- An intuitive interface with a convenient drag-n-drop editor.
- Mobile-friendly design.
- A variety of free and paid templates.
- An ability to create hybrid mobile apps.
- About 1,000 plugins you can integrate your app with.
- Code’s editable with Javascript.
- SQL Database Connector’s available to connect the built app to databases.
- An ability to deploy & host your app on the Bubble.io domain.
Cons:
- No code export.
- Limited functionality’s available for free.
- You need to buy a separate plan for each new app.
- Interface is rather complex, which makes it difficult to onboard for a newcomer.
- No ability to host an app on a custom domain.
#2. Fluid UI
Fluid UI is a tool helping designers, developers, product managers to wireframe and design apps, build minimum viable products using pre-built UI kits for Wireframing, Material Design, etc.
Pros:
- Over 2,000 built-in components are available in pre-built UI Kits for Material Design, iOS, Windows, Wireframing, and more.
- An ability to add existing graphic assets to your prototype.
- An ability to use mouse and touch gestures to build & design interactive app prototypes.
- Built-in review and feedback collecting feature.
- Downloadable Android and iOS preview apps.
- An ability to retrieve a ready-made project by scanning QR code with your smartphone.
Cons:
- App code is not downloadable.
- Only for app prototyping – no ability to build a full-fledged web app with a responsive design.
- Only 1 project you can create for free.
#3. UI Bakery
UI Bakery is a visual app builder allowing to create & design minimum viable products, white-label apps, and fully-functional web apps with the connected data & integrated APIs.
Pros:
- A very intuitive and understandable apps builder.
- Responsive design.
- Nebular Open Source UI library and Eva Design System – under the hood.
- A range of predefined layouts, widgets, and UI components.
- Downloadable code allowing you to use an app outside UI Bakery.
- Free ready-made web app templates & dashboards with an ability to request the one you need.
- Data connection & API integration’s available within the platform.
- An unlimited number of pages you can create in one project.
Cons:
- No ability to build a backend within the platform.
- Few third-party integrations available for now.
- Reusable UI components are not available (yet).
#4. Marvel
Marvel is a web app prototyping and design platform allowing you to create interactive prototypes and MVPs without writing even a line of code.
Pros:
- An intuitive and user-friendly UI.
- An ability to download assets, and generate CSS, Swift, or Android XML code.
- A big collection of pre-made assets, images, icons are available for use.
- An offline working mode.
- Third-party integrations (Jira, Confluence, Sketch, Microsoft, and many others).
- An ability to use GraphQL API to customise your workflows.
- An integrated user testing feature.
- Built-in collaboration for reviewing & collecting feedback in real-time.
- A lot of educational articles and video tutorials.
Cons:
- You can build only 1 project for free.
- Only 1 user working on the project is included in a free plan.
- An app branding feature is paid.
#5. Glide
Glide is an app-building tool you can use to turn Google spreadsheets into easy-to-use apps with no coding. You can build an app on top of a spreadsheet, or use a customizable template.
Pros:
- A convenient drag-n-drop editor.
- A huge library of ready-made templates, both free and paid.
- Allows you to build apps based on Google spreadsheets.
- Easy onboarding with no needed technical experience.
- Google and Zapier integration is available.
- A free app deployment feature to the glideapp.io domain.
Cons:
- Custom branding is paid.
- Very few integrations are available for now.
- Lacks customization flexibility.
- Limits in a number of data rows available in a free plan.
- Only a mobile layout is included in a free plan.
#6. AppSheet
AppSheet is an online app builder allowing you to create & design full-fledged mobile and desktop applications that are automatically compatible across different devices.
Pros:
- Quite a big choice of free ready-made templates.
- A created app fits for different screen sizes automatically.
- Custom app branding.
- Integrations with Salesforce, Dropbox, Amazon Web Services, and other third-party services are available.
- Useful videos, tutorials, etc., and how-to webinars on the YouTube channel.
- Offline working mode.
- Built-in application lifecycle monitoring & management.
Cons:
- The need to pay for each end-user (“active user”) of your created application.
- Only 10 users are available for free.
- Very limited development & design functionality you can use for free.
- The need to reach the support team to build your app on your SQL databases.
On a final note
The visual development platforms mentioned above greatly decrease the time from a product ideation and its MVP creation to its successful implementation. Once you build your app, you might want to export the code, give it to developers, let them connect a backend to a frontend you’ve created, etc. Be careful when choosing an apps builder that gives you as much development & design freedom as you need.
There’s a great number of other visual web app builders allowing designers and developers with different skill levels create MVPs before building a full-fledged product to test their ideas without overpaying for it.
Hope this overview of the most popular visual app makers will help you bring your next software solution to life faster, easier, with less costs and efforts.
Read More at Top 6 Tools For Creating an MVP (Designers’ Choice)
Starbucks Releases Brand New Cup Designs for The Holiday Season
Is it too early to get ready for the winter holidays? Starbucks says no!
We are all so excited for the holiday season. Not only does it mark the end of the year 2020, but it also means all those holiday traditions we have a love/hate relationship with will start again.
One of the traditions we have grown to love is the re-launching of Starbuck’s holiday drinks. And alongside the drinks themselves, Starbucks has released a new set of Holiday-themed cups!
Starting November 6th, drinks will be served in one of the four new holiday cups.
Starbucks has also added an additional bonus alongside the four newly designed cups. Whenever you purchase a handcrafted holiday drink, you receive a reusable holiday cup!
The brightly colored designs were crafted with the idea of spreading seasonal joy in mind.
According to Starbucks in their press release, “This year’s holiday design brings forward all the joyful elements of the holiday season in ribbons of Starbucks greens and a jolly red like a cozy holiday sweater.”
Starbucks has been carrying on this tradition of redesigning their holiday cups for over 20 years.
However, contrary to the mainstream traditions, Starbucks did not use the traditional red and green color pallet the holidays are known for. In fact, Starbucks ‘ first sets of holiday cups were actually purple. (very festive)
This year, their designs are meant to invoke the look of a silly, tacky, and joyful holiday sweater, similar to ones worn at office holiday parties. In our opinion, This design works well and is a welcomed choice that makes us recall nostalgic moments in the past holiday seasons.
Alongside its new design, Starbucks also has a new motto. Last year’s motto was “merry coffee” which appears to be a clever spin on the commonly used phrase “merry Christmas.”
“Carry the merry” is this year’s new slogan to accompany these new cup designs. We believe the main idea behind these words is to bring joy to those around us in this season (because we all need a little joy in 2020).
Whatever your opinions are on these new designs, we hope you have a happy holiday season this year!
Read More at Starbucks Releases Brand New Cup Designs for The Holiday Season
How to Detect When a Sticky Element Gets Pinned
Totally agree with David, on CSS needing a selector to know if a position: sticky;
element is doing its sticky thing or not.
Ideally there would be a
:stuck
CSS directive we could use, but instead the best we can do is applying a CSS class when the element becomes sticky using a CSS trick and some JavaScript magic
I love it when there is a solution that isn’t some massive polyfill or something. In this case, a few lines of IntersectionObserver
JavaScript and tricky usage of top: -1px
in the CSS.
Direct Link to Article — Permalink
The post How to Detect When a Sticky Element Gets Pinned appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Chapter 5: Publishing
Not long after HotWired launched on the web in 1994, Josh Quittner wrote an article entitled “Way New Journalism” for the publication. He was enthusiastic about the birth of a new medium.
I’m talking about a sea change in journalism itself, in the way we do the work of reporting and presenting information. The change that’s coming will be more significant than anything we’ve seen since the birth of New Journalism; it may be even more revolutionary than that. It has to be: Look at all the new tools we’re getting.
The title and the quote was a nod to the last major revolution in journalism, what writer Tom Wolfe would often refer to as “New Journalism” in the 1960s and 1970s. Wolfe believed that journalism was shifting in the second half of the 20th century. Writers like Hunter S. Thompson, Truman Capote, and Joan Didion incorporated the methods and techniques of fiction into nonfiction storytelling to derive more personal narrative stories.
Quittner believed that the web was bringing us a change no less bold. “Way New Journalism” would use the tools of the web — intertextual links, concise narratives, interactive media — to find a new voice. Quittner believed that the voice that writers used on the web would become more authentic and direct. “Voice becomes more intimate and immediate online. You expect your reporter (or your newspaper/magazine) to be an intelligent agent, a voice you recognize and trust.”
Revolutions, as it were, do not happen overnight, and they don’t happen predictably. Quittner would not be the last to forecast, as he describes it, the sea-change in publishing that followed the birth of the web. Some of his predictions never fully come to fruition. But he was correct about voice. The writers of the web would come to define the voice of publishing in a truly fundamental way.
In 1993, Wired included an article in their Fall issue by fiction writer William Gibson called “Disneyland with a Death Penalty.” The now well-known article is ruthlessly critical of Singapore, what Gibson describes as a conformist government structure designed to paper over the systemic issues of the city-state that undermine its culture. It was a strong denunciation of Singaporean policy, and coincidentally, it was not well-received by its government. Wired, which had only just recently published its fourth issue, was suddenly banned from Singapore, a move that to some appeared to incriminate rather than refute the central thesis of Gibson’s column.
This would not be Wired‘s last venture into the controversial. Its creators, Louis Rosetto and Jane Metcalfe, spent years trying to sell their countercultural take on the digital revolution — the “Rolling Stone” of the Internet age. When its first issue was released, The New York Times called it “inscrutable and nearly hostile to its readers.” Wired, and Rosetto in particular, cultivated a reputation for edgy content, radical design, and contentious drama.
In any case, the Singapore ban was little more than a temporary inconvenience for two driven citizens who lived there. They began manually converting each issue of Wired into HTML, making them available for download on a website. The first Wired website, therefore, has a unique distinction of being an unofficial, amateur project led by two people from a different country uploading copyrighted content they didn’t own to a site that lacked any of the panache, glitz, or unconventional charm that had made Wired famous. That would drive most publications mad. Not Wired. For them, it was motivation.
Wired had one eye on the web already, well aware of its influence and potential. Within a few months, they had an official website up and running, with uploaded back issues of the magazine. But even that was just a placeholder. Around the corner, they had something much more ambitious in mind.
The job of figuring out what to do with the web fell to Andrew Anker. Anker was used to occupying two worlds at once. His background was in engineering, and he spent a bit of time writing software before spending years as a banker on Wall Street. When he became the CTO of Wired, he acted to balance out Rosetto and bring a more measured strategy to the magazine. Rosetto would often lean on his experience in the finance world as much as his training in technology.
Anker assembled a small team and began drawing up plans for a Wired website. One thing was clear: a carbon copy digital version of the magazine tossed up on the web wasn’t going to work. Wired had captured a perfect moment in time, launched just before the crescendo of the digital revolution. Its voice was distinct and earned; the kind of voice that might get you banned from a country or two. Finding a new voice for the web, and writing the rules of web publishing in the process, would once again place Anker on the knife’s edge of two worlds. In the one corner, community. And in the other, control.
Pulling influence from its magazine roots, the team decided that the Wired website would be organized into content “channels,” each focusing on a different aspect of digital culture. The homepage would be a launching pad into each of these channels. Some, such as Kino (film and movies) or Signal (tech news) would be carefully organized editorial channels, with columns that reflected a Wired tone and were sourced from the magazine’s writers. Other channels, like Piazza, were scenes of chaos, including chat rooms and message boards hosted on the site, filled with comments from ordinary people on the web.
The channels would be set against a bold aesthetic that cut against the noise of the plain and simple homepages and academic sites that were little more than a bit of black text on a white background. All of this would be packaged under a new brand, one derived from Wired but very much its own thing. In October of 1994, HotWired officially launched.
Even against a backdrop of commercial web pioneers like GNN, HotWired stood out. They published dynamic stories about the tech world that you couldn’t find anywhere else, both from outside the web and within it. It soon made them among the most popular destinations on the web.
The HotWired team — holed up in a corner of the Wired office — frenetically jumped from one challenge to another, “inventing a new medium,” as Rosetto would later declare. Some of what they faced were technical challenges, building web servers that could scale to thousands of views a day or designing user interfaces read exclusively on a screen. Others were more strategic. HotWired was among the first to build a dedicated email list, for instance. They had a lot of conversations about what to say and how often to say it.
By virtue of being among the first major publications online, HotWired paved more than a few cow paths. They are often cited as the first website to feature banner ads. Anker’s business plan included advertising revenue from the very beginning. Each ad that went up on their site was accompanied by a landing page built specifically for the advertiser by the HotWired team. In launching web commercialization, they also launched some of the first ever corporate websites. “On the same day, the first magazine, the first automobile site, the first travel site, the first commercial consumer telephone company sites all went up online, as well as the first advertising model,” HotWired marketer Jonathan Nelson would later say.
Most days, however, they would find themselves debating more philosophical questions. Rosetto had an aphorism he liked to toss around, “Wired covers the digital revolution. HotWired is the digital revolution.” And in the public eye, HotWired liked to position themselves as the heart of a pulsing new medium. But internally, there was a much larger conflict taking place.
Some of the first HotWired recruits were from inside of the storm of the so-called revolution taking place on the Internet. Among them was Howard Rheingold, who had created a massive networked community known as the WELL, along with his intern Justin Hall who, as a previous chapter discussed, was already making a name for himself for a certain brand of personal homepage. They were joined by the likes of Jonathan Steur, finishing up his academic work on Internet communities for his Ph.D at Stanford, and Brian Behelendorf who would later be one of the creators of the Apache server. This was a very specific team, with a very specific plan.
“The biggest draw for me,” Behlendorf recalls, “was the idea of community, the idea of being able to pull people together to the content, and provide context through their contributions. And to make people feel like they were empowered to actually be in control.” The group believed deeply that the voice of the web would be one of contribution. That the users of the web would come together, and converse and collaborate, and create publishing themselves. To that end, they developed features that would be forward thinking even a decade later: user generated art galleries and multi-threaded chatrooms. They dreamed big.
Rosetto preferred a more cultivated approach. His background was as a publisher and he had spent years refining the Wired style. He found user participation would muddy the waters and detract from the site’s vision. He believed that the role of writers and editors on the web was to provide a strong point of view. The web, after all, lacked clear purpose and utility. It needed a steady voice to guide it. People, in Rosetto’s view, came to the web for entertainment and fun. Web visitors did not want to contribute; they wanted to read.
One early conflict perfectly illustrates the tension between the two camps. Rosetto wanted the site to add registration, so that users would need to create a profile to read the content. This would give HotWired further control over their user experience, and open up the possibility of content personalization tailored to each reader’s preferences. Rheingold and his team were adamantly against the idea. The web was open by design and registration as a requirement flew in the face of that. The idea was scrapped, though not necessarily on ideological grounds. Registration meant less eyeballs and less eyeballs meant less revenue from advertising.
The ongoing tension yielded something new in the form of compromise. Anker, at the helm, made the final decision. HotWired would ultimately function as a magazine — Anker understood better than most that the language of editorial direction was one advertisers understood — but it would allow community driven elements.
Rheingold and several others left the project soon after it launched, but not before leaving an impression on the site. The unique blend of Wired’s point of view and a community-driven ethos would give way to a new style on the website. The Wired tone was adopted to a more conversational style. Readers were invited in to be part of discussions on the site through comments and emails. Humor became an important tool to cut through a staid medium. And a new voice on the web was born.
The web would soon see experiments from two sides. From above, from the largest media conglomerates, and from below, writers working out of basements and garages and one-bedroom apartments. But it would all branch off from HotWired.
A few months before HotWired launched, Rosetto was at the National Magazine Awards. Wired had garnered a lot of attention, and was the recipient of the award for General Excellence at the event. While he was there, he struck up a conversation with Walter Isaacson, then New Media Editor for Time magazine. Isaacson was already an accomplished author and biographer — his 900 page tome Kissinger was a critical and commercial success — and journalist. At Time, he cultivated a reputation for exceptional journalism and business acumen, a rare combination in the media world.
Isaacson had become something of a legend at Time, a towering personality with an accomplished record and the ear of the highest levels of the magazine. He had been placed on the fast track to the top of the ranks and given enough freedom to try his hand at something having to do with cyberspace. Inside of the organization, Isaacson and marketing executive Bruce Judson had formed the Online Steering Committee, a collection of editors, marketers, and outside consultants tasked with making a few well-placed bets on the future of publishing.
The committee had a Gopher site and something do with Telnet in the works, not to mention a partnership with AOL that had begun to go sour. At the award ceremony, Isaacson was eager to talk to Rosetto a bit about how far Time Warner had managed to go. He was likely one of the few people in the room who might understand the scope of the work, and the promise of the Internet for the media world.
During their conversation, Isaacson asked what part of the Internet had Rosetto, who had already begun work on HotWired, excited him most. His response was simple: the web.
Isaacson shifted focus at Time Warner. He wanted to talk to people who knew the web, few in number as they were. He brought in some people from the outside. But inside of Time Warner there was really only one person trying his hand at the web. His name was Chan Suh, and he had managed to create a website for the hip-hop and R&B magazine Vibe, hiding out in plain sight.
Suh was not the rising star that Isaacson was. Just a few years out of college and very early in his career, he was flying under the radar. Suh had a knack for prescient predictions, and saw early on how publishing could fit with the web. He would impact the web’s trajectory in a number of ways, but he became known for the way in which he brought others up alongside him. His future business partner Kyle Shannon was a theater actor when Suh pulled him in to create one of the first digital agencies, Agency.com. He brought Omar Wasow — the future creator of social network Black Planet — into the Vibe web operation.
At Vibe, Suh had a bit of a shell game going. Shannon would later recall how it all worked. Suh would talk to the magazine’s advertisers, and say “‘For an extra ten grand I’ll give you an advertisement deal on the website,’ and they’re like, ‘That’s great, but we don’t have a website to put there,’ and he said, ‘Well, we could build it for you.’ So he built a couple of websites that became content for Vibe Online.” Through clever sleight of hand, Suh learned how to build websites on his advertisers’ dimes, and used each success to leverage his next deal.
By the time Isaacson found Suh, he was already out the door with a business plan and financial backers. Before he left, he agreed to consult while Isaacson gathered together a team and figured out how he was going to bring Time to the web.
Suh’s work had answered two open questions. Number one, it had proven that advertising worked as a business model on the web, at least until they could start charging online subscribers for content. Number two, web readers were ready for content written by established publications.
The web, at the time, was all promise and potential, and Time Warner could have had any kind of website. Yet, inside the organization, total dominance — control of the web’s audience — became the articulated goal. Rather than focus on developing each publication individually, the steering committee decided to roll up all of Time Warner’s properties into a single destination on the web. In October of 1994, Pathfinder launched, a site with each major magazine split up and spit out into separate feeds.
At launch, Pathfinderpieced together a vibrant collection. Organized into discrete channels were articles from Sports Illustrated, People, Fortune, Time, and others. They were streamed together in a package that, though not as striking as HotWired or GNN, was at the very least clear and attractive. In their first week, they had 200,00 visitors. There were only a few million people using the web at this point. It wouldn’t be long before they were the most popular site on the web.
As Pathfinder’s success hung in the air, it appeared as if their bet had paid off. The grown-ups had finally arrived to button up the rowdy web and make it palatable to a mainstream audience. Within a year, they’d have 14 million visitors to their site every week. Content was refreshed, and was often up to date with publications, and they were experimenting with new formats. Lucrative advertising deals marked, though not quite profitability, at the very least steady revenue. Their moment of glory would not last long.
There were problems even in the beginning, of course. Negotiating publication schedules among editors and publishers at nationally syndicated magazines proved difficult. There were some executives who had a not unfounded fear that their digital play would cannibalize their print business. Content on the web for free which required a subscription in print did not feel responsible or sustainable. And many believed — rightfully so — that the web was little more than a passing fad. As a result, content wasn’t always available and the website was treated as an afterthought, a chore to be checked off the list once the real work had been complete.
In the end, however, their failure would boil down to doing too much while doing too little at the same time. Attempting to assert control over an untested medium — and the web was still wary of outsiders — led to a strategy of consolidation. But Pathfinder was not a brand that anybody knew. Sports Illustrated was. People was. Time was. On their own, each of these sites may have had some success adapting to the web. When they were combined, all of these vibrant publications were made faceless and faded into obscurity.
Pathfinder was never able to find a dedicated audience. Isaacson left the project to become editor at Time, and his vacancy was never fully filled. Pathfinder was left to die on the vine. It continued publishing regularly, but other, more niche publications began to fill the space. During that time, Time Warner was spending a rumored fifteen million dollars a year on the venture. They had always planned to eventually charge subscribers for access. But as Wired learned, web users did not want that. Public sentiment turned. A successful gamble started to look like an overplayed hand.
“It began being used by the industry as an example of how not to do it. People pointed to Pathfinder and said it hadn’t taken off,” research analyst Melissa Bane noted when the site closed its doors in April of 1999, “It’s kind of been an albatross around Time Warner’s neck.” Pathfinder properties got split up among a few different websites and unceremoniously shut down, buried under the rubble of history as little more than rounding error on Time Warner’s balance sheet for a few years.
Throughout Pathfinder’s lifespan it had one original outlet, a place that published regular, exclusively online content. It was called Netly News, founded by Noah Robischon and Josh Quittner — the same Josh Quittner who wrote the “Way New Journalism” article for HotWired when it launched. Netly News dealt in short, concise pieces and commentary rather than editorially driven magazine content. They were a webzine, hidden behind a corporate veneer. And the second half of the decade would come to be defined by webzines.
Reading back through the data of web use in the mid-90’s reveals a simple conclusion. People didn’t use it all that much. Even early adopters. The average web user at the time surfed for less than 30 minutes a day. And when they were online, most stuck to a handful of central portals, like AOL or Yahoo!. You’d log on, check your email, read a few headlines, and log off.
There was, however, a second group of statistical outliers. They spent hours on the web every day, pouring over their favorite sites, collecting links into buckets of lists to share with friends. They cruised on the long tail of the web, venturing far deeper than what could be found on the front-page of Yahoo!. They read content on websites all day — tiny text on low-res screens — until their eyes hurt. These were a special group of individuals. These were the webzine readers.
Carl Steadman was a Rheingold disciple. He had joined HotWired in 1994 to try and put a stop to user registration on the site. He was instrumental in convincing Anker and Rosetto to do so via data he harvested from their server logs. Steadman was young, barely in his mid-20’s, but already spoke as if he were a weathered old-timer of the web, a seasoned expert in decoding its language and promise. Steadman approached his work with resolute deliberateness, his eye on the prize as it were.
At HotWired, Steadman had found a philosophical ally in the charismatic and outgoing Joey Anuff, who Steadman had hired as his production assistant. Anuff was often the center of attention — he had a way of commanding the room — but he was often following Steadman’s more silent lead. They would sometimes clash on details, but they were in agreement about one thing. “Ultimately the one thing [Carl and I] have in common is a love for the Web,” Anuff would later say.
If you worked at HotWired, you got free access to their servers to run your personal site — a perk attached to long days and heated discussions cramped in the corner of the Wired offices. Together, Anuff and Steadman hatched an idea. Under the cloak of night, once everyone had gone home, they began working on a new website, hosted on the HotWired servers. A website that cast off the aesthetic excess and rosy view of technology from their day jobs and focused on engaging and humorous critique of the status quo in a simple format. Each day, the site would publish one new article (under pseudyonyms to conceal author identities). And to make sure no one thought they were taking themselves too seriously, they called their website Suck.
Suck would soon be part of a new movement of webzines, as they were often called at the time. Within a decade, we’d be calling them blogs. Webzines published frequently, daily or several times a day from a collection of (mostly) young writers. They offered their takes on the daily news in politics, and pop culture, almost always with a tech slant. Rarely reporting or breaking stories themselves, webzines cast themselves as critics of the mainstream. The writing was personal, bordering on conversational, filled to the brim with wit and fresh perspective.
Generation X — the latchkey generation — entered the job market in the early ’90’s amidst a recession. Would be writers gravitated to elite institutions in big cities, set against a backdrop of over a decade of conservative politics and in the wake of the Gulf War. They concentrated their studies on liberal arts degrees in rhetoric and semiotics and comparative literature. That made for an exceptional grasp of postmodern and literary theory, but little in the way of job prospects.
The journalism jobs of their dreams had suddenly vanished; the traditional journalism job for a major publication that was enough to support a modest lifestyle, replaced by freelance work that paid scraps. With little to lose and a strong point of view, a group of writers taught themselves some HTML, recruited their friends, and launched a website. “I was part of something new and subversive and interesting,” writer Rebecca Schuman would later write, “a democratization of the widely-published word in a world that had heretofore limited its purview to a small and insular group of rich New Yorkers.”
By the mid-90’s, there were dozens of webzines to chose from, backed by powerful personalities at their helm, often in pairs like Steadman and Anuff. Cyber-punk digital artist Jamie Levy launched Word with Marissa Bowe as her editor, a bookish BBS aficionado with early web bona fides. Yale educated Stephanie Syman paired up with semiotics major Steven Johnson to launch a slightly more heady take on the zine format called Feed. Salacious webzine Nerve was run by Rufus Griscom and Genevieve Field, a romantic couple unafraid to peel back the curtain of their love life. Suh joined with Shannon to launch UrbanDesires. The Swanson sisters launched ChickClick, and became instant legends to their band of followers. And the list goes on and on.
Each site was defined by their enigmatic creators, with a unique riff on the webzine concept. They were, however, powered by a similar voice and tone. Driven by their college experience, they published entries that bordered on show-off intellectualism, laced with navel gazing and cultural reference. Writer Heather Havrilesky, who began her career at Suck, described reading its content as “like finding an eye rolling teenager with a Lit Theory degree at an IPO party and smoking clove cigarettes with him until you vomited all over your shoes.” It was not at all unusual to find a reference to Walter Benjamin or Jean Baudrillard dropped into a critique of the latest Cameron Crowe flick.
Webzine creators turned to the tools of the web with what Harvilesky would also call a “coy, ironic kind of style” and Schuman has called “weaponized sarcasm.” They turned to short, digestible formats for posts, tailored to a screen rather than the page. They were not tied to regular publishing schedules, wanting instead to create a site readers could come back to day after day with new posts. And Word magazine, in particular, experimented with unique page layouts and, at one point, an extremely popular chatbot named Fred.
The content often redefined how web technologies were used. Hyperlinks, for instance, could be used to undercut or emphasize a point, linking for instance, to the homepage of a cigarette company in a quote about deceptive advertising practices. Or, in a more playful manner, when Suck would always link to themselves whenever they used the word “sell-out.” Steven Johnson, co-founder of Feed, would spend an entire chapter in his book about user interfaces outlining the ways in which the hyperlink was used almost as punctuation, a new grammatical tool for online writers. “What made the link interesting was not the information on the other end — there was no ‘other end’ — but rather the way the link insulated itself into the sentence.”
With their new style and unique edge, webzine writers positioned themselves as sideline critics of what they considered to be corporate interests and inauthentic influence from large media companies like Time Warner. Yet, the most enthusiastic web surfers were as young and jaded as the webzine writers. In rallying readers against the forces of the mainstream, webzines became among the most popular destinations on the web for a loyal audience with nowhere else to go. As they tore down the culture of old, webzines became part of the new culture they mocked.
In the generation that followed — and each generation in Internet time lasted only a few years — the tone and style of webzines would be packaged, commoditized, and broadcast out to a wider audience. Analysts and consultants would be paid untold amounts to teach slow to move companies how to emulate the webzines.
The sites themselves would turn to advertising as they tried to keep up with demand and keep their writers paid. Writers that would go off to the start their own now-called blogs or become editors of larger media websites. The webzine creators would trade in their punk rock creds for a monkey suit and an IPO. Some would get their 15 minutes. Few sites would last, and many of the names would be forgotten. But their moment in the spotlight was enough to shine a light on a new voice and define a style that has now become as familiar as a well-wielded hyperlink.
Many of the greatest newspaper and magazine properties are defined by a legacy passed down within a family for generations. The Meyer-Graham family navigated The Washington Post from the time Eugene Meyer took over in 1933 until it was sold to Jeff Bezos in 2013. Advance Publications, the owners of Condé Nast and a string of local newspapers, has been privately controlled by the Newhouse family since the 1920s. Even the relative newcomer, News Corp, has the Murdochs at its head.
In 1896, Adolph Ochs bought and resurrected The New York Times and began one of the most enduring media dynasties in modern history. Since then, members of the Ochs-Sulzberger family have served as the newspaper’s publisher. In 1992, Arthur Ochs Sulzberger, Jr took over as the publisher from his father who had, in turn, taken over from his father. Sulzberger, Jr., despite his name, had paid his dues. He had worked as a correspondent in the Washington Bureau before making his way through various departments of the newspaper. He put his finger on the pulse of the company and took years to learn how the machine kept moving. And yet, decades of experience backed by a hundred year dynasty wasn’t enough to prepare him for what crossed his desk upon his succession. Almost as soon as he took over, the web had arrived.
In the early 1990’s, several newspapers began experimenting with the web. One of the first examples came from an unlikely source. M.I.T. student-run newspaper The Tech launched their site in 1993, the earliest example we have on record of an online newspaper. The San Jose Mercury Times, covering the Silicon Valley region and known for their technological foresight, set up their website at the end of 1994, around the time Pathfinder and HotWired launched.
Pockets of local newspapers trying trying their hands at the web were soon joined by larger regional outlets attempting the same. By the end of 1995, dozens of newspapers had a website, including the Chicago Tribune and Los Angeles Times. Readers went from being excited to see a web address at the bottom of their favorite newspaper, to expecting it.
1995 was also the year that The New York Times brought in someone from the outside, former Ogilvy staffer Martin Nisenholtz, to lead the new digital wing of the newspaper. Nisenholtz was older than his webzine creator peers, already an Internet industry veteran. He had cut his teeth in computing as early as the late 70’s, and had a hand in an early prototype for Prodigy. Unlike some of his predecessors, Nisenholtz did not need to experiment with the web. He was not unsure about its future. “He saw and predicted things that were going to happen on the media scene before any of us even knew about them,” one of his colleagues would later say about him. He knew exactly what the web could do for The New York Times.
Nisenholtz also boasted a particular skillset that made him well-suited for his task. On several occasions, he had come into a traditional media organization to transition them into tech. He was used to skeptical reproaches and hard sells. “Many of our colleagues way back then thought that digital was getting in the way of the mission,” Sulzberger would later recall. The New York Times had a strong editorial legacy a century in the making. By contrast, the commercial web was two years old; a blip on someone else’s radar.
Years of experience had led Nisenholtz to adopt a different approach. He embedded himself in The New York Times newsroom. He learned the language of news, and spoke with journalists and editors and executives to try and understand how an enduring newspaper operation fits into a new medium. Slowly, he got to work.
In 1990, Frank Daniels III was named executive editor of the Raleigh area newspaper News & Observer, which his great-grandfather had bought and salvaged in the 1890’s. Daniels was an unlikely tech luminary, the printed word a part of his bloodline, but he could see the way the winds were shifting. It made him very excited. Within a few years of taking over, he had wired up his newsroom to the Internet to give his reporters next generation tools and network research feeds, and launched an ISP to the greater Raleigh area for would-be computer geeks to buy Internet access (and browse N&O content of course) called NandO.net (News and Observer).
As the web began its climb into the commercial world, the paper launched the Nando Times, a website that syndicated news and sports from newswires converted into HTML, alongside articles from the N&O. It is the earliest example we have on the web of a news aggregator, a nationally recognized source for news launched from the newsroom of a local paper and bundled directly alongside an ISP. Each day they would stream stories from around the country to the site, updating regularly throughout the day. They would not be the only organization to dream of content and access merged into a distinctly singular package; your digital home on the web.
Money being a driving factor for many of the strategic angles, The Wall Street Journal was among the first to turn to a paywall. The Interactive Edition of the Journal has been for paid subscribers since it launched. It had the effect of standing out in a crowded field and worked well for the subscribers of that publication. It was largely a success, and the new media team at the WSJ was not shy about boasting. But their unique subscriber base was willing to pay for financially driven news content. Plenty would try their hand at a paywall, and few would succeed. The steady drum of advertising would need to work for most online publications, as it had been in the print era.
Back at The New York Times, Nisenholtz quickly recognized a split. “That was the big fork in the road,” he would later say. “Not whether, in my view, you charged for content. The big fork in the road was publishing the content of The Times versus doing something else.”
In this case, “doing something else” meant adopting the aggregator model, much like News & Observer had done, or erecting a paywall like The Wall Street Journal. There was even room in the market for a strong editorial voice to establish a foothold in the online portal race. There is an alternate universe in which the New York Times went head to head with Yahoo! and AOL. Nisenholtz and The Times, however, went a different way. They would use the same voice on the web that they had been speaking to their readers with for over a hundred years. When The New York Times website launched in January of 1996, it mirrored the day’s print edition almost exactly, rendered in HTML instead of with ink.
Just after launch, the website held a contest to pick a new slogan for the website. Ochs had done the same thing with his readers when he took over the paper in 1896, and the web team was using it to drum up a bit of press. The winner: “All the News That’s Fit to Print.” The very same slogan the paper’s readers had originally selected. For Nisenholtz, it was confirmation that what the readers wanted from The New York Times website was exactly the same thing they wanted when they opened the paper each day. Strong editorial direction, reliable reporting, and all the news.
In the future, the Times would not be competing simply with other newspapers. “The News” would be big business on the web, and The New York Times would be competing for attention from newswire services like Reuters, cable TV channels like CNN and tech-influenced media like CNet and MSNBC. The landscape would be covered with careful choices or soaring ambition. The success of the website of The New York Times is in demonstrating that the web is not always a place of reinvention. It is, on occasion, just one more place to speak.
The mid to late 90’s swept up Silicon Valley fervor and dropped it in the middle of Wall Street. A surge of investment in tech companies would drive the media and publishing industry to the web as they struggled capture a market they didn’t fully understand. In a bid for competition, many of the largest tech companies would do the opposite and try their hand at publishing.
In 1995, Apple, and later Adobe, funded an online magazine from San Francisco Examiner alumni David Talbot called Salon. The following year, Microsoft hired New Republic writer Michael Kinsley for a similar venture called Slate. Despite their difference in tone and direction, the sites would often be pitted against one another specifically because of their origins. Both sites began as the media venture of some of the biggest players in tech, started by print industry professionals to live solely online.
These were webzine-inspired magazines with print traditions in their DNA. When Slate first launched, Kinsley pushed for each structured issue on the website to have page numbers despite how meaningless that was on the screen. Of course, both the concept of “issues” and the attached page numbers were gone within weeks, but it served as a reminder that Kinsley believed the legacy of print deserved its place on the web.
The second iteration of webzines, backed by investment from tech giants or venture capital, would shift the timbre of the web’s voice. They would present as a little more grown up. Less webzine, more online magazine. Something a little more “serious,” as it were.
This would have the effect of pulling together the old world of print and the new world of the web. The posts were still written from Generation X outsiders, the sites still hosted essays and hit pieces rather than straight investigative reporting. And the web provided plenty of snark to go around. But it would be underscored with fully developed subject matter and a print sensibility.
On Salon, that blend became evident immediately. Their first article was a roundtable discussion about race relations and the trial of O.J. Simpson. It had the counter-cultural take, critical lens, and conversational tone of webzines. But it brought in the voice of experts tackling one of the most important issues of the day. Something more serious.
The second half of the 1990’s would come to define publishing on the web. Most would be forced to reimagine themselves in the wake of the dot-com crash. But the voice and tone of the web would give way to something new at the turn of the century. An independent web, run by writers and editors and creators that got their start when the web did.
The post Chapter 5: Publishing appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.