In my neighborhood in Portland, Oregon, many of the sidewalks are original - built when the neighborhood was coming together in the early part of the 20th century. You can locate stamps at intersections that have both obsolete street names - Sprague Street is now known as Rosemont; Margarette is now 34th Ave - and the names the contractors who poured the cement, along with the year they were poured. These small reminders of the recent past are fun to find, but point out a glaring inequity in their construction: These old sidewalks are not accessible, and not safe. An unimproved intersection The city is in the process of converting each of the city’s intersections into curb cutouts that are friendlier to those who may require assistance (wheelchairs, kneeling scooters, crutches, probing canes) getting up and onto sidewalks from the street. The brand new curb cutouts include a yellow rubberized traction pad that signals the transition between street and sidewalk, and there are eight on each improved intersection - two on each corner of a standard intersection. An improved intersection. This effort is happening not because the improvements and bright yellow traction pads are attractive, or because the contrast between the fresh cement and the old cement is nice to look at - but because it is the right thing to do for the citizens of Portland and those who have mobility issues who might otherwise need to be in the street in order to avoid the curb. This abides by the regulations set forth in American with Disabilities Act of 1990 (ADA). The benefits go beyond supporting only people who have disabilities, though - anyone who has tried to use a rolling suitcase on the sidewalk, pushed a baby stroller over a curb, or can’t ollie on a skateboard can attest to that. By doing the right thing, Portland has chosen to make their city more accessible to more of its citizens. In our web development projects, we often support clients who need to do the equivalent curb-cutout improvements. Their sites may have been beautifully designed, but fall short in visual and technical areas that would help make their site more accessible. By bringing the site up to a baseline of accessibility standards set forth by the WCAG, the site becomes more equitable, inclusive, and usable for more people. The add-on effect for the client is that they have just widened their potential customer base by not excluding people who may consume web information in different ways. The improvement process also helps shake out other technical issues around markup structure, meaning the site may become more SEO-friendly and may render better in a wider range of devices after the improvements are implemented. While these efforts may be initially driven by legal justification (avoiding ADA lawsuits), or for marketing reasons (reaching more customers), improving your site’s accessibility is the just and correct thing to do. Our process begins by using a suite of tools that analyze the website to identify problem areas. This includes using voice-reader to read the website’s content - not everyone who browses your website will use their eyes to do so. We also see how the site renders without styles applied, validate the markup of the site to ensure the proper document structure & hierarchy is established, and closely scrutinize how interactive elements work. Particularly complex interactive elements like carousels or interactive navigation menus may require an entire rebuild in order to be accessible, but the goal is to maintain the current design or as close to it as possible. The end result of such an effort should not sacrifice visual design or interactivity, nor should it even be noticeable to those users who use standard means to interact with websites. But for those who need assistance, the improvements are welcome and appreciated. For sites that we build from scratch, we design and develop with this equity in mind from the beginning. By starting off with a requirement of accessibility, the new site enters the digital world already with accessibility in place. The level of accessibility, set forth by WCAG standards - “A” to “AAA”, with the latter being the most strict - may be dictated by the customer’s requirements. Projects for larger clients, non-profits, or government clients typically have a minimum accessibility level mandate for digital properties. But even for those without the mandate, doing the right thing results in a site that behaves nicely across different input types and allows for a wider audience to engage with the site. Do you need help with your site’s accessibility? Are you concerned your site is unintentionally excluding users?

A friend and mentor once spoke to clients about his three questions (Yapp’s three rules) that any home page must answer. They were:   Who are you? What do you do? Who do you do it for? These questions are the most important goals to accomplish with any home page, as you need to quickly communicate to users about your brand and why should it be relevant to them. Why the urgency? Well, for any new or uninformed user, they will spend perhaps a total of < 3 seconds reviewing the site depending on where they came from and why they are there. It is important that they understand your brand and what it means to them.  This is part of the Brand and Messaging problem that most websites face. They fail to understand who they are and what they want to communicate to their customers. Don't try to be everything for everyone The second common challenge on many websites is part of the inherent value of the web and leads us to our next set of three rules: Focus, focus, focus!  Most company websites try to communicate to their audience everything that the company wants them to hear. The two challenges inherent here are a lack of priority and not focusing on what the user’s needs are. For any site — E-commerce, Marketing site, etc. — there are multiple audiences who come to the site. A company needs to prioritize its audiences into a hierarchy and prioritize its messaging and home page real-estate to communicating to them. This has as much to do with messaging as design and user-experience, but the lesson is the same: Focus on the most important users and tell what they need to hear to act on what you want them to act on. The second challenge stems from the very nature of the web. A website is available to everyone. However, it doesn’t need to speak to everyone who could possibly come to your site. Common secondary audiences for most company sites are press & analysts as well as job seekers. Both of these types of users are motivated to interact with your site and don’t need precious home-page real estate dedicated to them. They know where to find the news and careers sections (in the About Us) of your site with little effort as long as your navigation is clear and you have a site map. It's about your audience - not you My organizations architect their websites as a reflection of their internal structures and hierarchy.  This is a common mistake.  Websites should be designed to the needs of your audience in the way they want to engage with your brand and their needs.  Not designing your website's architecture, messaging, value proposition and navigation to your primary audience's needs will create frustration and lower levels of engagement.   Think mobile first The majority of website traffic today are typically from mobile or tablet devices.  Therefore, you need to ensure that the website be equally as effective in the mobile format as this will likely be the first impression your brand has with your target audience.  Designing a website to be effective in a smaller format is challenging and requires extreme diligence to properly tell your brand story and drive engagement.  Companies who neglect the mobile experience are making a big mistake.  However, we still find many companies that are not prepared for a mobile first world.  Brand experience needs to be consistent beyond the website When our team evaluates digital ecosystems and website for our clients, we are keen to examine the swim lanes in the customer's journey.  The reason is your customers are likely to visit varying digital properties representing your brand from Instagram, Facebook, LinkedIn, Email, Landing pages, Whitepapers, Mobile Applications and beyond.  If the brand experience and story are disconnected across these varying assets, you will create confusion and lose the ability to drive home the key brand impressions you hope to achieve.   Basic website evaluation benchmarks: 1. Clearly articulate your Brand Value Proposition through a structured Messaging Architecture which addresses the main three questions: Who are you? What do you do? Who do you do it for? 2. Focus your efforts on your home page on convincing the primary users of your website on what you want them to do. 3. Prioritize your messaging through clear design and user-experience on focused messages to your users satisfying what they need to know and how you want them to act. 4. Is your website designed to the needs of your audiences first? 5. Is your mobile optimized website effective? 6. Are all your digital properties working in synergy to reinforce your brand? Our Offer If you would like a complementary review and assessment of your website, we would be delighted to evaluate your website and provide some insights and thoughts.

CREATING USEFUL STYLE GUIDES FOR WEB PROJECTS - PART 2 In part two of two, we'll explore different ways to create styleguides and what works and doesn't about each method. Throughout, we'll look at examples. If you haven't read the first part of this series from last month, or need a refresher, click here. We have already defined what a styleguide is, and what types of visual definitions need to be in them - and I've made recommendations about when to create them. This post will dive into the different ways of actually creating the styleguide. Method One: Static Old School I'm calling this the Static Old School method: A designer or production artist lays out a styleguide based on the design system for the project in Illustrator or Photoshop. They export it as a PDF, get client approval, and move on to layout. The PDF is handed off to the developers to begin their baseline work. Pros: Gets the job done Gives designer complete control over formatting and layout, which may be useful for client presentations Cons: Not easily updated - requires a designer to maintain Does not keep designers honest - a label indicates that this blue color is #3c89bf — but is it actually? Not interactive - cannot demonstrate rollover states or add code snippets Developers cannot easily highlight text to inspect additional properties that may not be defined, such as line height Verdict and Recommendation: On a small project or one with a short timeline, this approach will suffice. There are enough "cons" to avoid it if you can though. Method Two: Use a Plugin! Since a designer has her layout in a design program like Photoshop or Sketch already, wouldn't it be really convenient if a magic button could be pressed and a styleguide is automatically created? Fear not, this magic button exists. The most well-known style guide generator is Craft by Invision. Invision is an online collaborative prototyping tool that allows designers to upload their layouts, request reviews or comments from other team members or clients, and simulate interaction by creating clickable hotspots. If a layout is uploaded correctly, developers can interact directly with the app to inspect fonts, measurements, and CSS properties: Invision has created a plugin called Craft that allows designers to automatically generate a styleguide based on all of the existing properties in their layout. The plugin will analyze all of the font properties and colors used in your various page layouts and generate a separate static styleguide for you. This can then be exported as a PDF / static styleguide and shared, or uploaded to Invision for review and for developer inspection. I created a demo of the plugin in action which you can view below: https://youtu.be/BzENA_cibds https://www.youtube.com/watch?v=BzENA_cibds Craft is not the only game in town - zeroheight uses a Sketch or Photoshop plugin to generate a styleguide based on a layout as well. There are additional steps and control given to this tool, since zeroheight lets you create products with technical specs as parameters (such as the design and screen resolution). In this way, this solution is a combination of a local design plugin and an online management tool. Unlike Craft, the designer has more control about what ends up in the layout to begin with - avoiding the scenario where every single color or font on the layout ends up in the styleguide that later has to be removed. Zeroheight will also allow designers to define entire component definitions, which make for a much more robust styleguide. Once the designer defines the parameters and what layers should be included, zeroheight will export the generated guide to its server, where the interactive styleguide is automatically created based on the export. This is where your living styleguide is put for further editing, viewing and sharing with other team members. Unlike Craft, where the generated styleguide is just another page in your layout, the zeroheight styleguide is managed within its website. A risk I see with this approach is if a design changes but the styleguide is not synced, there's no guarantee a developer is seeing the latest changes. Deciding on a proper workflow can help mitigate that risk. zeroheight has other bells & whistles, such as JIRA and Slack integration, that can notify team members when the styleguide defintion is updated. It's unclear how much this service costs, but since it's more than just a plugin, I am guessing there is a subscription model involved. The website provides no pricing model, no demo (I found a few on YouTube) and no trial version, so you don't really know what you're getting without having to go through a sales call and presentation. Likely, the people making the decision to purchase the product aren't the people who are sussing out whether the tool works for them or not, which can require a lot of legwork for the team just to find out whether the tool is going to do what they want or not. Pros: Reduces the amount of work required by designers to create the styleguide May help keep designers honest - in the Craft demo video above, you can see I had multiple similar shades of grey and orange that were not intended. In a real-world example, I'd need to decide whether those colors are still required, or remove them from my layout. Removes any ambiguity in the definitions - yes, that really is 60pt font, and yes that really is #3c89bf Excellent Sketch support Can be easily re-exported as your design changes to capture more definitions Cons: Requires the layout to be defined first While it may keep designers honest, they may not go back to actually address duplicates or ambiguous definitions in their primary layout, leading to more ambiguity. Outputted result is still static unless you use Invision or zeroheight, which is not free Not sure if it works as well for Photoshop, unknown whether it exists for other layout tools at all. No way to make Craft interactive Craft only captures colors and fonts; doesn't capture button styles or any additional design language components that should be in a complete styleguide (zeroheight is more comprehensive) Verdict and Recommendation: This is better than doing it entirely by hand if you're using Sketch (and even moreso if your team is using Invision anyway), but the output result of Craft is not enough to be considered a complete styleguide, and there's no real way to make it interactive. zeroheight shows more promise, but without the ability to try the product out, you have to hope that that it does everything I think it does. I can't make a strong recommendation for or against it at this point without knowing more or having some hands-on time with it. Method Three: Generators Upon Generators! David Hund was kind enough to compile an enormous list of code-driven generators, of which ... there are many: Without the luxury of going through each individual tool and testing it out, these are very cool for a few reasons - they can live in your existing code projects which means you are not creating these based on the prototype layout, but actually basing it on production code. The end result is an interactive styleguide based on code you've already written. Some of the tools will automatically generate the styleguide, meaning you can continue writing the code for your project and the styleguide gets continuously updated; others require more input from the developer. A few examples and demos for some selected items are below: Stylemark, which will generate a nice page for you based on markdown format; Patternlab React Styleguidist KSS, which generates a styleguide based on /* comments */ developers put into their CSS and HTML templates. The comments are parsed by the tool, which outputs a HTML file with visuals and code snippets. Storybook.js, a UI development environment for JS projects (React, Vue Angular) Many of these tools have the same or similar functionality as their counterparts, and many of them won't apply to your specific project based on the platform it is living on. That said, there are many to choose from for a variety of platforms - and additional research and trial & error is likely the only way to find the one with the right feature set for you. While these are pretty slick and ultimately devs like me are easily impressed by any tool that "automagically" does something, the big unspoken issue here to me is that these tools cut out the designer from the process, and developers don't just make up the styles from scratch in the development phase. Thus, these tools are not a replacement for a styleguide, since a designer is going to need something to even start the project - they are likely going to *still* need the designer to hand something off statically at the start. So, that means these tools are likely a way to convert the styleguide from its initial form to a living form - but are not a replacement or the only styleguide to be created on the project. Pros: Reduces the amount of work required by developers to create an interactive styleguide Can be integrated with source control so there's never a disparity between the core site code and the generated styleguide Generates something that can be pushed to a public (or protected) URL and visited / referred to easily - eliminating the "Which is the the latest styleguide PDF?" question Since the styleguides are based on existing code, what is in them accurately represents the current state of the project. Can be continuously updated to reflect the latest styles and code Cons: An overwhelming number of choices A lot of these options are open-source and/or undermaintained - meaning no support if something doesn't work Ability to implement may require developer resources and hours that aren't available The tool you like may not be compatible with your framework or project platform Learning curve range depending on which tool is used and how involved it is. Often dependent upon learning and installing additional technology (various node packages, third-party dependencies, etc) Totally cuts out the designers from the process, unless they are also writing the code. Since the styleguides are based on existing code, what is in them may not *accurately* represent what the design was *supposed* to be! Verdict and Recommendation: Smashing Magazine has a nice, more in-depth review of some of these tools - though it's a few years old - worth checking out if you are compelled to move in the generator direction. Other Web Applications We've already briefly talked about Invision, which is more of an online prototyping tool. It becomes more than just that when using the Craft plugin. However, there are also online services tailored specifically for generating styleguides, for a fee. Two additional examples are Frontify and Patternry; zeroheight would also fit into this category as outlined above. FRONTIFY The approach for Frontify is to allow users to upload or add specifications via WYSIWYG editor. This could be done before, during, or after high-fidelity design by a designer, and can easily be updated as code snippets become available by the developer. It appears to allow for a collaborative approach that could be integrated at various points along the phase of a project. Frontify Style Guide from Frontify on Vimeo. Frontify offers additional services, such as a media library for storing image assets, and what they call a Brand Portal, for entire brand identity suite. The product aims to be a central repository for any given brand or product's guidelines, to be shared by designers, marketers, and developers alike. PATTERNRY If Frontify is trying to be everything to everyone, Patternry narrows its range of services and its target user. In Patternry, building a style guide requires a developer to write code that is hosted within Patternry. The target user for this product is a UI designer / developer - the product does not run off of drag-and-drop or WYWIWYG tools. The end result is more control. The component definitions inside Patternry seem to depend upon production-ready CSS and JS to function, introducing some concern about keeping code in sync between your code repository and Patternry. This also limits the collaboration aspect, as a designer without code experience can't dive in to make adjustments. Verdict and Recommendation: It's clear that these types of services wish to make the creation of sharable and maintainable style guides quite easy, but also wants to hitch users into a subscription model where they are dependent upon them as part of their workflow. That may not be in your budget, and may be yet another thing to track (along with GitHub, JIRA, Basecamp, etc). Some of the features are fairly robust, though, and the idea of not having to create any code from scratch is appealing. The feature set of Frontify seems pretty broad, so if your team can define a workflow that works for everyone, it may be a very useful suite of tools that act as a central repository for your style guides and brand standards. With Patternry, it seems to be more of a framework for an online styleguide than an actual generator or creator. That may be okay, but keep in mind that it's likely going to introduce code disparity between your repository and styleguide. Using a code-based generator tool as described above may be more useful. Some More Online Styleguide Examples FRONTIFY Frontify - covered above - used their own tool to generate their styleguide. Always nice to see a company pracitcing what they preach and using their own tools. I like how it mixes both visual definitions, when to use what, and provides code samples. They also categorize the sections into Design, Identity and Communication. Very thorough, but goes beyond a styleguide for a website and into the brand identity / pattern library for the entire product. View it here. Frontify ColorsFrontify Typography YELP Yelp provides its styleguide online publically, which provides nice code-toggle ability. The visual layout of the styleguide is less engaging than the previous example, which is perhaps emphasises the utilitarian nature of it. View it here. Yelp IslandsYelp Color - including SASS variablesYelp Typography - Including utility class definintions for front-end developers or content editors PAGEUP PEOPLE This is a styleguide that clearly took a lot of time to build. I like how this styleguide includes code samples for each component along with usage notes to remind authors how to utilize each component. I think their foundation area could use some more baseline code samples (typography, for example) but it possible that is baked into their global stylesheet, and developers would not have to touch it. View it here. PageUp color - nicely designed color blobs, though users have to hover above them to view the hex value.PageUp Buttons - Very thorough with helpful do's and don'ts and code samples.PageUp Component example - includes code sample and usage guidePageUp Typography - This section looks nice but is lacking for more detail around the values (line spacing / letter spacing, weights, etc) More examples: via CreativeBloq — Three Online Style Guides That Do It Right via Hubspot — Apple, Google & Starbucks: Inside the Web Design Style Guides of 10 Famous Companies Conclusion The takeaways here are that there will not likely be a single tool for solving the styleguide portion of the project. Nor should the responsibility of creating styleguide be assigned to only the designer or developer — it should be a collaborative process between technology and creative. We have found out that in some cases, two styleguides will need to be created - one static, perhaps for client approval and tech handoff; and one dynamic / interactive that will be the evergreen and living document to be referenced. It's also clear that everyone has their own definition of the right order of operations for creating styleguides. In my previous post, I had recommended starting with the styleguide, but also recognize that this workflow is not possible for everyone or for every project. Some of the tools outlined above will be more flexibile than others to fit your approval process and work style. I would suggest that an important criteria for selection is the ability for the tool or methodology to be flexible enough to work with you, rather than one that forces you to change your workflow in order to use. Hopefully this post has given you a good overview on the types of methods available and the pros and cons of each. Resources and Citations Styleguides.io List of Styleguide Generators An In-Depth Overview of Living Style Guide Tools Three Online Style Guides That Do It Right Apple, Google & Starbucks: Inside the Web Design Style Guides of 10 Famous Companies

CREATING USEFUL STYLE GUIDES FOR WEB PROJECTS -PART 1 Today's post is a two-parter. In this post, we are exploring the use of style guides and how they can help in all aspects and phases of a digital project by minimizing ambiguity and setting definable parameters that can be validated and tested against. A good style guide will help reduce hours spent by all parties throughout the phases of the project. In a future post, we'll take a look at some examples of style guides, what works about them, and explore some tools that can help the creation of these guides. What is a styleguide? A styleguide sets rules around how things look and behave. Styleguides are the projects visual source of truth for both user interface (UI) and user experience (UX). More focussed than brand guidelines, a styleguide is intended to be the visual and functional requirements definition for websites or applications. A styleguide will pull in components from its parent design system which may include overall brand guidelines, design system or an established pattern library. If a brand has very specific and strong brand guidelines, design system or an existing pattern library, a project's styleguide will be derived heavily from it or may not need to be developed at all. However, if these parent documents do not define every component in the project, a styleguide should be created to cover these cases.   Via A List Apart Style guides exist in different formats - anything from a static PDF or image, to a single web page or an entire microsite or cloud-based prototype can be used for host the styleguide. Of course, they're more useful as univerally accessible documents that are easily updated, so web-based styleguides are popular for a reason. Thus, the best styleguides are built as a collaboration between the design team and the development team. Not only will they define how things look, they'll also define how to build those things with the correct code. This example from Lonely Planet exemplifies this full-fledged approach, covering both the visual aspect of components and layout but also specifying a code pattern for how to build the components. The main point is that it is a visual tool that can be referenced by multiple people playing their respective roles. There may be a written component to it, but it is primary visual. A styleguide can be developed in conjunction with the main layouts, or as a template before the main layouts are defined. Ideally, the guide is a deliverable that the client approves with the designs. Via Lonely Planet Why use a style guide? While front-end technlogy seems to change on a monthly or weekly basis, the phases that a project goes through often do not. Whether your business practices waterfall, agile, hybrid, or some other methodology to get the job done, at some point, there is a handoff between creative and tech. A layout has to get out of a designers head, into a document, approved, and handed off to the developers for implementation. This could happen once, or it could happen many times over the course of a single project, but the transition point and hand-off process is always there. This handoff process is a crucial step and it is important to minimize abiguity so that specifications can be met. Via Barricade Developers love specification and requirements (maybe not actually _writing_ them, but that's another topic). By putting rules and definitions behind everything from how the user is supposed to interact with something on screen to the way the layout changes at a particular breakpoint, a specification can be met - and tested against. These requirements become the acceptance criteria that define whether the task was completed or not. Without these set of rules, ambiguity creeps into the picture. Ambiguity is a developers — and ultimately, a user's — worst nightmare. Ambiguity allows room for error, leaves things open to interpretation and subjectivity, and ultimately, cannot be tested against. Much nature abhors a vacuum, developers abhor ambigutity. Design, however, can be more comfortable in the realm of the ambiguous. Sometimes this is intentional. Art, by definition, is open to interpretation and can be intentionally unintentional (if that makes sense). More often than not, though, it's a result of shifting business requirements (see Peter's post) or a pressing time or budget constraint that does not allow the team to fully flesh out how some new component will function or look. Since one of the styleguide's purpose is to fulfill the role of a requirements document for UX and UI, it forces designers to design to the requirements. This is particularly useful after a project has been deployed and there are enhancements or iterative changes to be made, particularly by another designer. Via Auth0 When to create a styleguide While we don't always have the luxury of endless budget and time, I would argue (and so would Brad Frost) that spending design hours to create a styleguide before high-fidelity design even begins will pay off on the back-end of the project. By starting with the styleguide, designers are taking into account the UX decisions done in wireframing phase, along with any brand standards to apply. The styleguide will lay down the groundwork for the high-fidelity design. The completed styleguide should be handed off to the client for approval, which can then be given to production designers *and* to front-end developers. In a web project, while the designers are beginning their high-fidelity mockups, the developers are using the completed and approved styleguide to write base CSS that will drive the majority of the site's look and feel. Since the client has already approved the style guide, there should be no danger in having to "re-do" anything in rounds of revision. What's in a good styleguide? In creating a styleguide, the bare minimum should be included, for all required breakpoints: LAYOUT Responsive breakpoints Grid system DESIGN COMPONENTS Icons Image Galleries Thumbnails TYPOGRAPHY Font Faces Heading Styles and Type Sizes Paragraph / Body Styles and Type Sizes List Styles (ordered; unordered) and Type Sizes Any other specialized definitions, like form label styles or subheading styles INTERACTIVE AND NAVIGATIONAL ELEMENTS Buttons - rest, hover states Links - rest, hover states Main Nav - rest, hover, active states Breadcrumb Nav Togglers - on, off states Tool Tips - on, off states Alert boxes Modal / overlay boxes Custom form elements (checkboxes, radio buttons, selects, etc) COLOR PALETTE Primary colors and when to use them Secondary, tertiary colors and when to use them ANIMATION Loading icons Progress bars Any other animations the layout may require Resources and Citations Design System vs Pattern Libraries vs Style Guides: What's the difference? Nielsen Norman Group - Front-End Style-Guides: Definition, Requirements, Component Checklist Atomic Design by Brad Frost Styleguides.io - Collection of Styleguide Examples Sajio George Brand Styleguide Examples Stay Tuned for Part two of this post, where I will evaluate some helpful tools to streamline the process of creating a styleguide, as well as take a closer look at more examples and why they work!

Chatbots are nothing new, but there have been some significant changes to make chatbots the hot new marketing platform like mobile messaging apps, artificial intelligence, and voice tech. Bot-enabled conversation will quickly become the new digital interface. Not the browser. Not smartphone apps. Bots. And voice will become the dominant input method.   Welcome to the conversation frontier.

Google Maps’ ride services design is a more mature version of its old one. Instead of returning a simple list of ride options in your area, the new design includes a map, which displays cars near you, just as if you were using the ride service’s native app. Using Uber through Google Maps comes with an added bonus that Uber doesn’t provide - while on the way to your destination, Maps will pull up pertinent information such as menus, hours, and anything else you may need to know. Your car is here.

All awkwardness aside, the Internet of Things is finally entering an age of adolescence. While much of the original consumer-grade hype has focused on turning lights on and off and tracking fitness, the next few years will see an inventive wave of maturity—and advertisers seem keen to play a part. Tinkering with the future.

What does it mean to have an emotion? It seems obvious that having one means feeling it. If you’re happy but don’t know it, in what sense could you actually be happy? Even if we do feel an emotion, there are parts associated with it that we aren’t usually aware of. Emotions are complicated things.

Services like Tinder and Hinge are no longer shiny new toys, and some users are starting to find them more frustrating than fun. Tired thumbs.

Nintendo's next major step in gaming is a mystery no more. Today, the hardware formerly known as "NX" — and now officially dubbed Switch — has debuted, and here it is. Switch is a transforming console/handheld hybrid that can be pulled apart into a portable gaming system. It's powerful enough to run The Elder Scrolls V: Skyrim and also features its own, detachable micro-controllers for more party-like settings. Totally nerding out.