theprd / tags / stuff

Tagged with “stuff” (5)

  1. Karen McGrane – Mobile Strategies for Your Content » UIE Brain Sparks

    Karen: Yeah. I think part of the root of it is that there’s this ethos that we really all try to evangelize in the mobile space which is you should serve the same stuff to every platform.

    You should aim content parody where you aren’t thinking of mobile and desktop is being completely different silos, completely different experiences. Your goal, first and foremost, should be to get all of the same stuff onto every platform.

    You could see how a client, a decision maker could reasonably say, “Oh, OK. We’re supposed to serve the same stuff to every platform. Well, we’ll just take what we have and we’ll try to serve it on mobile.”

    You need to explain, “Well, yes, you should serve the same stuff but it can’t be exactly what you have on the desktop right now. Your going to have to go through and evaluate whether it’s any good.”

    “You are going to need to assess whether, what’s a page? The container of a page is likely to be different on desktop versus mobile or on a larger screen size versus a smaller screen size.”

    If your thinking about going responsive, you probably need to strike a balance between those two form factors and do something different than what you might do for either one, if you were thinking of each on in isolation.

    You might need to develop alternative forms of some chunks of content. The shorter headline example is one that I use a lot. You might need additional little summaries for pages that can serve for navigation, or other cues that help people to know what’s going to happen when they tap.

    You might even need to think about how you present content. What’s the right form factor in which to present content? One example that people always give me is, “Well, what if the whole point of this page is this comparison chart, a big product comparison chart. That’s why the user is coming to the page?”

    I’m like, “Well, the point of the page isn’t the table. The point of the page is that the user wants to compare two products or something that might be presented as a sizing chart, in a tabular format, on the desktop.

    A tabular format might be the best presentation on a large screen size, but that doesn’t mean that the user’s goal is to look at a table. It means that the user’s goal is to say, “Will these pants fit me?” Or, “Which of these two products meets my needs?”

    You might need to come up with a completely different separate presentation or interaction model on a smaller screen size. You have the same content and the sizing chart is not going to change.

    The product comparison is not going to change but on a smaller screen size, maybe you need to turn it into some kind of Q & A wizard format, or drop down, or you have to find different visual and physical techniques to communicate the same information.

    http://www.uie.com/brainsparks/2013/12/10/karen-mcgrane-mobile-strategies-for-your-content/

    —Huffduffed by theprd

  2. Jason Grigsby – Responsive Web Design with Mobile in Mind » UIE Brain Sparks

    Jason: There is a lot of that, that can be done, and there are businesses that are amazing at that. Etsy does, in their annual reports, they now have a performance section, because performance is such a big part of what they do and such a competitive advantage that they’re reporting out on these things.

    And trying to make improvements in performance all the time. I think that there are a bunch of businesses that are really, really smart about this stuff and are looking at it across the whole spectrum of what needs to be done.

    One of the things that I find the most interesting is that, inside the performance community, people have gotten down to the point where they’re talking about different types of specific JavaScript instructions and which ones are faster and not as fast and things of that nature.

    That’s awesome. I’m glad that they’re doing that. That is not the stuff that I spend my time worrying about or talking to people about, because what I find over and over again is it’s the simple things that aren’t getting done.

    What I’m looking at in responsive design is really about, “OK, well, what is the approach that you need to do to make responsive design performant? What are the five things that you really need to keep in mind? Where do you get the most bang for your buck?”

    Generally, I think, even if we weren’t talking about responsive design, maybe if we were just talking about Web design in general. There’s just a handful of things. This isn’t something that’s responsive-design-specific.

    It’s not something that we end up talking about in the workshop or anything, because it’s not responsive-design-specific. There’s this simple instruction for a server to turn on Gzip, which is a form of compression, and it is in Apache, which is the most popular Web server.

    It’s three lines of configuration. It’s not even code. It’s just three lines saying, “Turn this thing on.” It’ll take text files and reduce the size of them 80 percent.

    It’s brain-dead simple, right, but I’ll bump into sites all the time that don’t have that on, and then designers that don’t know that that’s a thing. They don’t even know how to check to see whether their back-end developers have done it.

    The designer doesn’t have to know those three lines, right? All they have to know is, “Hey, this is something that I should look for,” and there are tools to check to see whether your page is doing this.

    They need to know that it is really, really simple, so that they can’t get somebody telling them that it’s more difficult than it is. Just say, “Look, this needs to be turned on. It would make such a big difference for our users, and it would save us money because we don’t have to pay as much for bandwidth.” All this sort of stuff.

    The things that I focus on are really at that level. They’re either things that designers should know, particularly when it comes to responsive design, how do you handle images, how do you do mobile-first responsive design, why is this important.

    They’re not designed to be like, “OK, let’s go calculate things and let’s go figure out the nitty-gritty of performance.”

    There’s something really satisfying about performance, because it’s the one bit of design that you do that you can actually measure results on, so it can get a little addictive. It’s like it’s got its own built-in gamification to it.

    If people were to start thinking about it from a responsive-design perspective and then get excited about it and go do other things, that would be awesome.

    That’s not what I focus on. I’m just like, “OK, you guys are going to do responsive design. Here’s how to do it well. Here’s, big-picture, what you have to keep in mind. Here are the challenges you’re going to bump into.

    Here’s how you do it in a way that works well and is per-formant, and here’s why you should care about performance. Here’s why it’s actually something that, as a designer is actually, impacts your job and you have the power to change it.”

    Sorry. That was a little rant. I just think that people get turned off of performance, for some reason that I don’t quite understand, when you don’t have to get into the nitty-gritty to just understand some big stuff that will make huge impacts.

    http://www.uie.com/brainsparks/2014/01/07/jason-grigsby-responsive-web-design-with-mobile-in-mind/

    —Huffduffed by theprd

  3. Brad Frost – Creating Responsive Interfaces » UIE Brain Sparks

    Brad: Yeah. I think that, yeah, more or less, that’s it.

    Molecules are a couple tags stitched together. You might have just a search form that’s comprised of search label, an input, and a button, and that is a self-contained little assembly of stuff that does something.

    Atoms by themselves, the tags are all really abstract and floating around in space. You don’t really see, inherently, just from looking at that level, how these things might be useful. It’s like, “Well, that’s nice.” It’s helpful at an at-a-glance sort of level. Then you start combining them into these little packages, these little molecules, and now they could actually start doing something.

    You might have your primary navigation as a molecule, your search form as a molecule, and stuff like that, and then you put those molecules together into a header organism. Now your header organism contains your logo atom and contains your navigation molecule, it contains your search-form molecule, and all those things operate at this standalone, reusable component.

    From there, then you start stitching these organisms together and finally start building these sort of page-level things, like templates and then, ultimately, pages, which we don’t have to get into.

    The idea is that you have these little clusters of elements, and then you combine those together into more complex clusters of stuff. The whole idea is to basically establish this really sound, really deliberate interface, where everything is being built up with the intention of creating a system that’s built for reuse, built for scalability.

    Certainly helps with responsive design because, again, you’re able to treat these problems at the component level rather than at a page level. Also, just from being future-friendly — you’re establishing these nice rules and guidelines and constraints, and this goes inside of this, which means that the new hire you hire four months down the line can understand how things are put together and why things are put together in the way that they are.

    I think that in my experience using this and helping create this, what we’re doing now, why we’re doing this, is that it’s no longer feasible to just throw over a handful of page templates to a client and just say, “Here’s your site. Have a nice day. Make sure I get my final paycheck.” It’s not enough to do that anymore. We have to be a lot more deliberate with this.

    We have to give them better tools, better resources, so that we don’t come back next year and, all of a sudden, they’ve changed the color of green and they’ve put this thing next to this thing and they’ve created a bunch of new code all on their own, in different patterns and stuff, and it all looks like a big, giant, Frankenstein mess.

    In part, that’s your fault if that happens, simply because you didn’t give them the library of components, you didn’t give them the building blocks, the LEGO bricks, so that if they need to add a new section to the site. If they need to add another widget, or an organism or component or whatever you want to call it, they have a language to choose from and make informed decisions. I think that that’s really, really cool.

    In fact, one of the clients that we first did this on — actually, the very first client that I introduced this whole atomic-design, Pattern Lab concept — was TechCrunch. I was actually just on their site last night and noticed that they had added a different component to the site. You read the article, and then there was an extra little “You might also like” sort of thing.

    Now, we had our own version of that, and that’s still there, but then they added a separate “You might also like these stories.” What I found is that they used the interface patterns that we provided them to construct an entirely new module.

    http://www.uie.com/brainsparks/2014/01/16/brad-frost-creating-responsive-interfaces/

    —Huffduffed by theprd