Scrambling in Snowdonia

At the end of last week, Klaas (one of my best friends) and I drove to from Belgium to Wales dead-set on scrambling up Tryfan's North Ridge and hiking the Ogwen Valley in Snowdonia.

Scrambling means hiking up steep, rocky terrain using your hands, without the need for ropes or any other kind of protection. It's something between hiking and rock climbing.

Tryfan's North Ridge silhouette next to lake Lyn Ogwen.17 people died on Tryfan the past 30 years, and 516 parties had to be rescued. While the scrambling on Tryfan is rarely technically challenging, it can be dangerous and difficult at times (video of Klaas scrambling), especially when carrying heavy backpacks. Tryfan shouldn't be taken lightly.

It took us five hours to make it to the top — and it's taking me four days to recover so far. After we reached the top, we descended a few hundred meters and found a patch of grass where we could set up our tent.

Our campsite on a ridge on the back of Tryfan. The views were spectacular.

Carrying those heavy backpacks paid off not only because we were able to bring our camping supplies but also because Klaas carried up a steak dinner with cocktails — a late birthday surprise for my 40th birthday. Yes, you read that correctly: a steak dinner with cocktails on top of a mountain! It was a real treat!

During dinner, the weather started to turn; dark clouds came in and it started to rain. By night time the temperature had dropped to 2 degrees Celsius (35 degrees Fahrenheit). Fortunately, we were prepared and had hauled not only a tent and a steak dinner up the mountain, but also warm clothing.

The temperatures swung from 20ºC (68ºF) during the day time to 2ºC (35ºF) during night time. In the evenings, we were forced to put on warm clothes and layer up.

What didn't go so well was that my brand new sleeping pad had a leak and I didn't bring a repair kit. Although, sleeping on the ground wasn't so bad. The next morning, when we opened our tent, we were greeted not only by an amazing view, but also by friendly sheep.

The next two days, we hiked through the Ogwen Valley. Its wide glacial valley is surrounded by soaring mountains and is incredibly beautiful.

After three days of hiking we made it back to the base of Tryfan where it all started. We felt a big sense of accomplishment.

Selfie taken with Klaas' iPhone 8. Me pointing to the Tryfan's North Ridge where our hike began just three days earlier.We hadn't taken a shower in four days, so we definitely started to become aware of each other's smell. As soon as we got to Klaas' Volkswagen California (campervan), we showered in the parking lot, behind the car. I ended up washing my armpits four times, once for each day I didn't shower.

For more photos, check out my photo album.
Source: Dries Buytaert www.buytaert.net


The ebbs and flows of software organizations

This week I was in New York for a day. At lunch, Sir Martin Sorrell pointed out that Microsoft overtook Apple as the most valuable software company as measured by market capitalization. It's a close call but Microsoft is now worth $805 billion while Apple is worth $800 billion.
What is interesting to me are the radical "ebbs and flows" of each organization.
In the 80's, Apple's market cap was twice that of Microsoft. Microsoft overtook Apple in the the early 90's, and by the late 90's, Microsoft's valuation was a whopping thirty-five times Apple's. With a 35x difference in valuation, no one would have guessed Apple to ever regain the number-one position. However, Apple did the unthinkable and regained its crown in market capitalization. By 2015, Apple was, once again, valued two times more than Microsoft.
And now, eighteen years after Apple took the lead, Microsoft has taken the lead again. Everything old is new again.
As you'd expect, the change in market capitalization corresponds with the evolution and commercial success of their product portfolios. In the 90s, Microsoft took the lead based on the success of the Windows operating system. Apple regained the crown in the 2000s based on the success of the iPhone. Today, Microsoft benefits from the rise of cloud computing, Software-as-a-Service and Open Source, while Apple is trying to navigate the saturation of the smartphone market.
It's unclear if Microsoft will maintain and extend its lead. On one hand, the market trends are certainly in Microsoft's favor. On the other hand, Apple still makes a lot more money than Microsoft. I believe Apple to be slightly undervalued, and Microsoft is to be overvalued. The current valuation difference is not justified.
At the end of the day, what I find to be most interesting is how both organizations have continued to reinvent themselves. This reinvention has happened roughly every ten years. During these periods of reinvention, organizations can fall out out favor for long stretches of time. However, as both organizations prove, it pays off to reinvent yourself, and to be patient product and market builders.
Source: Dries Buytaert www.buytaert.net


Our vacation at Acadia National Park

For our 2018 family vacation, we wanted to explore one of America's National Parks. We decided to take advantage of one of the national parks closest to us: Acadia National Park in Maine.

Day 1: Driving around Mount Desert Island

An aerial photo of our rental house near Bar Harbor, Maine.We rented a house on the water near Bar Harbor. So on our first morning we explored the beach area around the house. In good tradition, the boys collected some sticks to practice their ninja moves and ninja sword fighting. Both also enjoyed throwing their "ninja stars" (rocks) into what they called "fudge" (dried up piles of seaweed). The ninja stars landed with a nice, soggy "plop".

When not being pretend ninjas, Axl's favorite part of exploring the beach was finding sea life in the tidal pools. For Stan it was collecting various crab shells in hopes to glue them all together to make a whole crab.

Next up, we drove around Mount Desert Island, stopped for lunch, visited Bass Harbor Lighthouse and explored the rocks. On the way, we saw multiple deer, which triggered a memory for Stan that he saw a "man deer".

Stan: I saw a man deer once!Vanessa: What? A man deer? You mean like a half man and half deer?Stan: Yes.Vanessa: LOL! Like a mythical creature?Stan: Yes.Dries: You saw a deer that was half man and half deer in real life?Stan: Yes, you know a deer that is a man.Laughter erupted in the carEveryone: Oh, you mean a male deer!?Stan: Yes.

Descending the steep stairs to the rocks near Bass Harbor Lighthouse.Stan standing on one of the many rock formations at Acadia National Park.Acadia's rocky landscape dates back to more than 500 million years ago. It's the result of continents colliding, volcanoes erupting, and glaciers scraping the bedrock. It all sounds very dramatic, and I'm sure it was. Sand, mud and volcanic ash piled up in thick layers, and over millions of years, was compressed into sedimentary rock. As tectonic plates shifted, this newly formed rock was pushed to the surface of the earth. The end result? One of the most stunning islands in the United States.

Day 2: Hiking on Acadia Mountain

This beautiful landscape is perfect for hiking so on the second day of our vacation, we decided to take our first hike: Acadia Mountain Trail. The forested trail quickly makes its ascent up Acadia Mountain, with a few sections of relatively steep rock formations that require a bit of scrambling. Once at the top, the trail took us along the ridge of the mountain with great views into Somes Sound and the Atlantic Ocean.

The stunning view from Acadia Mountain Trail.Coming down was harder than going up; the trail down is steep. Vanessa and I often had to sit down and hop off the rocks. Axl and Stan, on the other hand, hopped down the rocks like the elves in The Hobbit. We were happily surprised how much they loved hiking. Axl even declared he enjoyed hiking much more than walking, because "walking is exhausting" to him.

Descending Acadia Mountain Trail was harder than expected.After our hike we went to Echo Lake for a swim and picnic. It is a gorgeous fresh water lake in a spectacular setting. Imagine a beautiful mountain lake, next to 800 foot (250 meter) steep rocks. We even saw two bald eagles flying by when swimming. Pretty magical!

Day 3: Watching the sunrise on Cadillac Mountain

We woke up at 4am to the glaring noise of our alarm clock. There are few sounds worse than the blaring of an alarm clock, especially on vacation.

I feel tired, but also excited. We drank a quick cup of coffee, and hit the road. By 5am we were up at the top of Cadillac Mountain, a different part of Acadia National Park. Cadillac Mountain is famously the first spot in the United States to see the sunrise.

The view from the top of Cadillac Mountain minutes before sunrise.For the photographer in me, it also meant that I got to see the park in its most beautiful light. As the sun started to peek through, the colors first turned purple and blue, and then slowly yellow, until the morning sun covered everything in golden hues.

The view from the top of Cadillac Mountain minutes after sunrise.To watch the sunrise from the top of a mountain is an experience worth getting up early for.

Day 4: Rain day

Raining today! In the morning, Vanessa made cornmeal griddle cakes with fresh Maine wild blueberries. Stan gave them a 10 on 10, and while Axl liked them a lot but he indicated he prefers it when the blueberries are still whole (hadn't popped during the cooking process) … our little food critics! :)

We played a variety of board games throughout the day. It's fun to watch the boys start to think more strategically. In between games, Vanessa taught Stan how to make chocolate peanut butter chip cookies, and Axl how to make pasta bolognese. Both of the boys wrote down their recipes so they can make them again — we can't wait to try these!

Playing a game of Pente.We also love our long dinner conversations about life. Axl said he has a great business idea. I hope he doesn't mind me sharing it here but it's a "self-charging smartphone". He is determined to sell his idea to Apple for $3.5 million dollars. This prompted a long conversation about how it's not enough to have a great idea, but how it takes a lot of determination and team work to bring such an idea to life. In that conversation, we covered a range of topics from working hard, to wealth, giving back, and what really matters in life to be happy.

Day 5: Out on the water

We started the day with a Kubb tournament (a lawn game that involves throwing wooden batons), where Stan and I won the first game, and then Stan gave the second game away to Vanessa and Axl. Nonetheless it was a lot of fun!

After lunch we made our way into Bar Harbor and then boarded a boat to explore the Acadia coastline. On the boat tour we learned more about the animals indigenous to the area, the history of the park and how Bar Harbor came to be. On our trip we saw grey seals, Egg Rock Lighthouse and another bald eagle.

Egg Rock Lighthouse in the distance.
It wouldn't be a vacation in Maine without lobster and chowder. When we got back on land, we went to a lobster shack where we were able to pick out our lobsters, and then they were boiled in custom fishermen's nets in large pots filled with seawater outside over fires fed with local wood. The lobsters were cooked to perfection! Stan was in heaven as he had been craving lobster for weeks.

Lobsters cooking in large pots filled with seawater.Day 6: Exploring Pemetic Mountain

After a quick work call in the morning, we're off for a hike. We hiked Pemetic Mountain today; roughly 4 miles (6.5 kilometer) and 1,200 feet (365 meter) of elevation. Getting to the top involves some steep and strenuous uphill hiking, but the views of the ocean, surrounding forests, lakes and other mountains make it worth it. The appeal is not just in communing with nature, but also connecting with the boys.

After our hike we grabbed lunch at Sweet Pea's Cafe. The name is misleading; it's not really a cafe, but a farm to table restaurant, and one were you are literally eating at the farm. All the food was fresh and delicious, and we all agreed to come back at a future trip (which is why I decided to capture the name in my blog).

My favorite part of the day was undeniably the dance party we had in the kitchen just before dinner. No, there are not pictures of it. The party climaxed with Neil Diamond's Sweet Carolina which involved us dancing and singing along. More than Neil Diamond, I love that we can dance and sing together without caution or reservation, and just be our true selves.

Day 7: Hiking Bubble Rock

We're kicking of the day with Axl and Stan doing some homework; math, reading, writing, reading the clock, etc. The entire month of August, we've been doing homework for about one hour a day. As it is often the case, it's frustrating me. I continue to be surprised how many mistakes they make or why they still don't seem to understand basic concepts. We'll keep practicing though!

In the afternoon, we decided to hike Bubble Rock, named after one of the most famous boulders in Maine. Bubble Rock is a huge boulder that was placed into this unique position, teetering on the edge of a cliff, millions of years ago by a glacier. It makes you wonder how it remained in place for all these years. Of course, we tried to push it off, and failed.

Giving the famous Bubble Rock at Acadia National Park a little push.Day 8: Chilling in the backyard

The last day of our vacation, we just hung around the house. We played Spikeball (also called Roundnet), soccer, made pizza on the grill, collected shells on the beach, caught up on some work, and relaxed in the hammock. At home, we live in a condominium so we don't have a backyard or a large grill — just a small electric one. So playing games in the backyard and grilling actually makes for a wonderful experience. And with that last relaxing day, the Maine part of our vacation came to an end. We're headed back to the Boston suburbs, because the next day, we have a flight to Europe to catch. By the time you're reading this, we'll probably be in Europe.

Vanessa making pizza on the grill, which has become a summer vacation tradition.Some photos were taken with my Nikon DSLR, some with my iPhone X and some with my DJI Mavic Pro. I wish I could have taken my Nikon on all our hikes, but they were often too strenuous to bring it along.
Source: Dries Buytaert www.buytaert.net


My POSSE plan for evolving my site

In an effort to reclaim my blog as my thought space and take back control over my data, I want to share how I plan to evolve my website. Given the incredible feedback on my previous blog posts, I want to continue to conversation and ask for feedback.

First, I need to find a way to combine longer blog posts and status updates on one site:
Update my site navigation menu to include sections for "Blog" and "Notes". The "Notes" section would resemble a Twitter or Facebook livestream that catalogs short status updates, replies, interesting links, photos and more. Instead of posting these on third-party social media sites, I want to post them on my site first (POSSE). The "Blog" section would continue to feature longer, more in-depth blog posts. The front page of my website will combine both blog posts and notes in one stream.
Add support for Webmention, a web standard for tracking comments, likes, reposts and other rich interactions across the web. This way, when users retweet a post on Twitter or cite a blog post, mentions are tracked on my own website.
Automatically syndicate to 3rd party services, such as syndicating photo posts to Facebook and Instagram or syndicating quick DrupalCoin updates to Twitter. To start, I can do this manually, but it would be nice to automate this process over time.
Streamline the ability to post updates from my phone. Sharing photos or updates in real-time only becomes a habit if you can publish something in 30 seconds or less. It's why I use Facebook and Twitter often. I'd like to explore building a simple iOS application to remove any friction from posting updates on the go.
Streamline the ability to share other people's content. I'd like to create a browser extension to share interesting links along with some commentary. I'm a small investor in Buffer, a social media management platform, and I use their tool often. Buffer makes it incredibly easy to share interesting articles on social media, without having to actually open any social media sites. I'd like to be able to share articles on my blog that way.
Second, as I begin to introduce a larger variety of content to my site, I'd like to find a way for readers to filter content:
Expand the site navigation so readers can filter by topic. If you want to read about DrupalCoin, click "DrupalCoin". If you just want to see some of my photos, click "Photos".
Allow people to subscribe by interests. DrupalCoin 8 make it easy to offer an RSS feed by topic. However, it doesn't look nearly as easy to allow email subscribers to receive updates by interest. Mailchimp's RSS-to-email feature, my current mailing list solution, doesn't seem to support this and neither do the obvious alternatives.
Implementing this plan is going to take me some time, especially because it's hard to prioritize this over other things. Some of the steps I've outlined are easy to implement thanks to the fact that I use DrupalCoin. For example, creating new content types for the "Notes" section, adding new RSS feeds and integrating "Blogs" and "Notes" into one stream on my homepage are all easy – I should be able to get those done my next free evening. Other steps, like building an iPhone application, building a browser extension, or figuring out how to filter email subscriptions by topics are going to take more time. Setting up my POSSE system is a nice personal challenge for 2018. I'll keep you posted on my progress – much of that might happen via short status updates, rather than on the main blog. ;)
Source: Dries Buytaert www.buytaert.net


How to Implement Accessibility in Agency Projects: Part 2

In part 1 of my series, How to Implement Accessibility in Agency Projects, I discussed some of the high-level challenges faced when implementing accessibility in client service companies and how we’re approaching them at Viget.

Talking about accessibility is relatively easy, but when project constraints like timelines and budgets are involved, putting it into practice can be challenging. We've been working on this at Viget and in part 2 of this series, I’ll share some concepts and tips that we're using to make accessibility part of every project.

Thinking About Accessibility

Making accessibility part of your team’s work can be challenging and requires a deliberate effort. At Viget, we've found that building empathy, company-wide education, and re-framing how we think to be valuable strategies.

Cultivate Empathy

If you’re reading this, you likely work at a computer… a lot. You also may have customized your setup to enhance the way you like to work. In short: you’re a “power user”. That’s great for productivity but bad for empathy. The more ingrained we are in our setup the harder it is to understand how other people use and experience their computer and the web. We can easily forget that we are not like our users. It's challenging enough to keep in mind that most people are less savvy, use less-than-cutting-edge hardware, or don’t have a high-speed internet connection. If you don’t have direct experience with disabilities (either yourself or someone in your life), it takes deliberate effort gain empathy for people who interact with the web in ways that are different from you.

You may be able-bodied now, but things happen as we journey through life that can cause us to become temporarily or permanently disabled. Has anything ever prevented you from using your computer in your normal way? Perhaps a broken thumb affected your ability to use the mouse, LASIK surgery made it difficult to focus on your screen for a week or two, or maybe your trackpad just gave out (all of these happened to me). Having even temporary dependence on accessible technologies, like I did with keyboard access and font zooming, can give us a new perspective and appreciation for the importance of building accessible products.

“By designing for someone with a permanent disability, someone with a situational disability can also benefit.” pic.twitter.com/H38S2Dw0LL— David Storey (@dstorey) October 1, 2015

Try these tips for gaining better insight into how people with various disabilities use the Web:

Take the #NoMouse challenge and spend some time navigating by keyboard.
Learn the basics of how to use a screen reader and try listening to how pages are read.
Install Chrome extensions like NoCoffee or Funkify to experience browsing with various disabilities.
Check out many of the other simulations from WebAIM.
Hold an empathy-building workshop for your team or company where you challenge the group to perform a specific task, like selecting a round-trip flight, using only the keyboard or with one of the Funkify personas enabled.

Educate Across the Company

Lone accessibility advocates, however passionate, aren't going to make much of a lasting impact on accessibility awareness company-wide — they can’t be everywhere all the time, and if they leave the company their influence goes with them. At Viget, we found that the most successful strategy for creating a lasting company value was to harness those with a passion for accessibility to speak, write, and lead training sessions. By framing accessibility knowledge as a higher level of expertise and empowering everyone to own their role’s portion of accessibility, we quickly saw a higher level of buy-in and enthusiasm.

To that end, we built the Interactive WCAG: a tool for filtering and sharing the daunting Web Content Accessibility Guideline (WCAG) spec in a digestible format. The spec can be filtered to only view a certain level (A, AA or AAA) and a role's responsibility (copywriting, visual design, user experience design, development, or front-end development). It also creates a shareable URL so that it can be easily sent to a colleague or client.

Try these ideas for getting a discussion going in your office:

Lead by example — begin with your own work and show what good accessibility looks like.
Do a lunch-and-learn presentation or offer to speak at a team or company all-hands meeting.
Depending on how your company is structured, approach other discipline or project teams and ask if an accessibility presentation can get on an upcoming meeting agenda. Make sure the presentation is tailored to the concerns of that group.
Write about accessibility on your company's blog.
Hold an empathy-building session or build an empathy lab where coworkers can get a better understanding of some people's barriers to using the web.
Attend a local accessibility Meetup and offer to host a meeting at your office.
Invite an outside accessibility expert to speak at a company or team meeting (in person or remote).

Think of Accessibility as a Core Part of Usability

The introduction of the iPhone and the explosion of internet-connected portable devices that followed was a sea-change moment for web developers. At the time, we were too busy re-learning how to build for the web to realize how beneficial these devices would be for people with disabilities. Our need to start accounting for new patterns of input and output beyond the desktop computer and mouse wound up being a boon to accessibility on the web. We're now accustomed to thinking about patterns that coincide with a variety of disabilities:

Better readability and responsive designs for small screens also benefit those with low vision who might prefer to zoom their browser to see content better.
Making targets, like buttons, large enough for a finger on a touchscreen also makes it easier for users with fine motor control disabilities that can still use a mouse to target and click.
Considering content in smaller chunks and writing tight for small screens is great for helping those with cognitive or memory disabilities, like ADD/ADHD, focus on the page's task.
The popularity of touch devices largely killed hovers as a primary way of revealing and interacting with content. This was good for keyboard users because it meant that we stopped relying on the mouse hover and started designing and coding for the click as the primary way to interact with things.

Tips for Making Accessibility Part of Your Day-To-Day Work

Here are some curated tips from the Viget team on how we're implementing accessibility in our daily work:

Design

“Check your palette at every step of the way so that you don't have to adjust for contrast later on. Keep the contrast checker open in a tab for easy access.”

- Mindy Wagner, Art Director

Content

“Keyboard testing is a quick and important way to QA a site. When going through pages using your keyboard, remember to use shift+tab to make sure keyboard users can move both down and up a page in a logical way. You can find some sneaky things that way, especially when elements appear/disappear when scrolling.”

“Always dig into contrast errors when using WAVE or a similar tool. Don’t consider it an error just because it is flagged as one - look at the details and see what level and font size it's failing.”

- Becky Tornes, Senior Project Manager

User Experience

Question :hover with extreme prejudice.
Edit labels and microcopy for simplicity and directness.
Disable CSS to see if a UI "reads" logically when color, shape, alignment, emphasis, and other visual design elements are absent.
Balance working memory with the amount of content on a page.
Be consistent and predictable, particularly with navigation.
Poke yoke your data inputs. Error prevention > error resolution.

- Todd Moy, Former Senior User Experience Designer

Front-End Development

“Purposely become a keyboard-only user as often as possible. You can start small. Try giving yourself a user goal, like "As a user, I need to be able to search for careers" and try to complete it using only the keyboard. If you're developing on a Mac, you may need to adjust browser and OS settings before getting started.”

- Chris Manning, Senior Front-End Developer

Don't Reserve Accessibility for Just Production Code

When prototyping or test-coding a new feature, always build it to be accessible. Even if it's for a small internal audience or just yourself, considering accessibility at a nascent stage will get it baked in from the beginning and, most importantly, means you won't have to re-think a feature's structure or interaction model later. And who are we kidding... when the going gets tough these prototypes sometimes make their way into production.

Learn HTML and Use It Semantically

Using the correct markup for the task is the easiest way to get accessibility for free. This can be pretty straightforward if you're coding by hand but more challenging if you're using a framework or helper that outputs markup for you. The benefits, though, are significant:

Sectioning elements allow screen reader users to jump around the page quickly.
Good use of headings, similarly, lets screen reader users understand a page's content structure and jump to just want they want.
Using frequently built-from-scratch elements like <button>, <a> and <select> correctly instead of meaningless <div>'s provides all of the expected interactivity (keyboard focusable, clickable and correctly read by a screen reader) without the extra work of having to add it in with JavaScript.

Not using the correct element, or trying to reproduce a native control from scratch, can lead to bigger headaches down the road and a true adding-accessibility-takes-more-time result.

Support Flexibility

Building for accessibility isn't about just one disability. There's a broad range of disabilities to keep in mind and it can feel overwhelming at times. Building flexibility into your interfaces and interactions helps ensure broader access. What does that mean? To an extent, with responsive design, we're already doing it. Accounting for multiple kinds of input (mouse and touch) and output (small to large screens) makes our sites better able to accommodate a variety of situations.

Sometimes we unknowingly disable flexibility. For example, one common practice is locking a mobile browser's zoom level to ensure that the site fits the screen or to prevent some gestures from interfering with interactions. This has the unintended consequence of preventing users with vision disabilities from zooming the page to make text or images easier to see.

Ask, “does my site’s responsive mobile version disable pinch & zoom?” If it does, you’ve created an anti-user design. @cameronmoll #aeaaus— Jeffrey Zeldman (@zeldman) October 5, 2015

Prioritize Accessible Content Over Accessible Experience

We're frequently tasked with creating richly interactive sites. That's the fun part of what we do, right? In a perfect situation with plenty of time, we'd be able to make that experience accessible to everyone. I don't know about you, but I'm still waiting for that unicorn project to come along (hint: it won't). When the task of making a complex piece of functionality or experience accessible is daunting, prioritize making sure that the content is accessible. With enough time, we could make anything accessible. But when faced with deadlines and budgets, making something accessible over nothing is the better tradeoff.

An example of this concept in practice was a map page we created for a client. This page was designed with a map of clickable pushpins that brought up a little info overlay. Rather than trying to figure out how to make the SVG map accessible to keyboards and screen readers, the design already included an identical text list that we were able to rely on. The solution was to make the map inaccessible to keyboards and screen readers. The map script that we used created the pushpins as <span>'s (see using semantic HTML above) rather than <button>'s so it was already inaccessible out-of-the-box. To make it invisible to screen readers we added aria-hidden="true" to its outermost wrapper.

The result is perfectly accessible content without the added time and expense of trying to make the map accessible. This was a win for accessibility and a win for the budget! Now, of course it's possible to make the map accessible with some extra effort, but instead, those hours could be spent on other features and contributed to delivering the site on time and on budget.

Conclusion

Creating more accessible products and experiences is an essential and rewarding endeavor but carries unique challenges for those of us working in client service companies. Rather than give up or wait for clients to ask, we’ve found that the practices I outlined in this article lead to a lasting culture at Viget that values thinking about accessibility throughout a project and throughout the company. Here are just a few examples from our experience working on some fun, beautiful and disability-specific projects. Do you have any tips to share? Comments? Criticism? We'd love to hear about it below!


Source: VigetInspire


A Focus on Blockchain

I shared this with my newsletter subscribers today… I thought I’d share it here as well, especially since I’m tired af and I written way too much copy and content for one day.
So, here it is…

If You Could Invest in “The Internet”…
… before it became a huge thing… knowing what you know now… you wouldn’t hesitate, right? Same thing might be said of mobile (or the iPhone and/or Apple) before it took over the entire world and accelerated our world into a mobile-first culture.
You’d go all-in, right? I mean, you’d drop everything to be part of that movement, correct?
Well, this is exactly what I feel about blockchain (and bitcoin and cryptocurrency).
Consequently, I’ve decided to share some pretty big news today, which is this: I’m working with my brother on a collection of products and apps in the blockchain space. These include a mobile app, a vibrant community, and a brand-spankin’ new YouTube Channel called “Decentralized“.
And I couldn’t be more excited. Truly. Blockchain may very well be the most significant technological advancement that I will ever have the pleasure of experiencing first-hand.
So, as I mentioned, I’m going all-in on this project and it’s going to be my singular focus for quite some time.
The timing is great too, by the way, as yesterday I finished my 365-day vlogging experiment… that was a great mental and physical exercise (and thanks for everyone who followed along!).
So, anyways, I hope you join me on this exciting new adventure. I’ll be sharing more along the way, as I typically do, and I’ll be spending more time on this brand new YouTube Channel as well.
Finally… if I can say anything (and I think I’ve said it already at this point… beating dead horse…) you should seriously take a look into Bitcoin, cryptocurrency, and perhaps most importantly blockchain technology.
It’s going to change all of our lives for the better… might as well get a piece of the action, right?
Love you all. Let me know how I can serve you!

john

The post A Focus on Blockchain appeared first on John Saddington.
Source: https://john.do/


New in Basecamp 3: To-do Groups

A little thing that’s a big deal.For years, we’ve been making to-do lists in Basecamp that looked like this:See those === DIVIDERS ===? We were trying to group related to-dos together within a list. All we wanted was to bring a little structure, and an extra ounce of organization, to a single flat list.We weren’t alone. Whenever a customer showed us how they use Basecamp, we’d inevitably run into a similar === DIVIDER === pattern. They were trying to do what we were trying to do.We were all hacking it. As of today, the silliness is over. No hacks required!We just launched To-do Groups in Basecamp 3!What’s a group?A group is like a sublist on a list. It’s organization, it’s structure, it’s an envelope, it’s a box. It has a header, and to-dos grouped below.The anatomy of a Basecamp 3 to-do list with two groupsWhen you drag a group header, all the to-dos under that header move with it. If you click the header, you go to a separate page with just those to-dos on it. You can discuss a group, you can archive a group, you can see all the to-dos completed in a specific group, you can ungroup a group. You can make as many groups on a list as you’d like (but you can’t make a group inside a group — that would lead to an eventual, over-organized mess).How to make a groupThere are two ways to make a group of to-dos on a list.To make an empty group (which you can fill later), click the hamburger menu to the left of the list name. Select “Add a group”Make a group from the list header2. To group together to-dos that are already on a list, shift-select multiple to-dos (hold down shift, and click the hamburger menu to the left of each to-do you want to group), and select the “Group them” item in the menu.Group some existing to-dos togetherAdding to-dos to a groupThere are a couple ways to add to-dos to a group.Simply drag an existing to-do down below a group header. It’ll snap into place and be part of that group for now on (or until you drag it back out).Or click the hamburger menu next to the group name, and select “Insert a to-do” from the menu.Insert a new to-do right below a group headerMoving all to-dos a group togetherTo move a group of to-dos together, just click+hold the drag handle/menu to the left of the group header. Then drag above or below any other group. To make it easier to move, the header will collapse to a single line and the number of to-dos you’re moving will show up as a little badge to remind you you’re moving multiple to-dos at once. Like this:Isolating a group for review or discussionOne of the great bits about groups is that clicking on the group header will take to a separate page which isolates just that group of to-dos. Now you can focus in, have a discussion about the entire group, add to-dos to that group, and see all the completed items for that group.On the left we have a full list with a few different groups. On the right, I’ve clicked on the “Android” group header and now I just have open/completed to-dos from that group, plus a conversation about the group below.Ungrouping to-dosMake a group, but decide you’d rather have them “loose” again? Easy, just select the menu next to the group name, and select “Ungroup”. The group header slides out, fades away, and the to-dos jump up to the top of the list where any other loose, ungrouped to-dos are listed.Ungroup to-dos that were grouped togetherUse casesTo-do Groups are excellent for organizing work around disciplines (to build this feature designers need to do this, programmers need to do that, and when QA finds something fishy they can log things, too). Or for moving work through phases. You can drag to-dos between phases, set up work in advance, and even keep future phases empty until it’s time to slot work in.A couple of simplified examples of how groups bring structure to to-do listsAnd here’s an example from an actual project we have running right now:BONUS: Add to-dos from anywhere in a listEven if you have no need for groups, we just made Basecamp 3’s to-do lists better for everyone. Before you could only add to-dos from the bottom of the list using the “Add a to-do button”.Before today, the “Add a to-do button” was the only way to add to-dos to Basecamp lists.If you wanted to add a to-do at the top of a list, or somewhere in the middle, you had to first add from the bottom and then drag the to-do into place.No longer!Now you can add to-dos anywhere in a list. Just click the hamburger menu next to any existing to-do, any existing group header, or the list title itself, and you’ll see an “Insert a to-do” menu item. Select that and you’ll be able to add a to-do right in place.The big ideaWe set out to incorporate and improve on hacked patterns we saw in the wild. We did that. We set out to make to-do lists more powerful without making them more complicated. We did that. We set out to keep to-do lists the same for those who didn’t want to use groups. We did that. We set out to prevent over-organization and sub-sub-sub-lists. We did that. We set out improve baseline to-do list interactions (like adding anywhere). We did that.In addition to these new features being available on the web-based version of Basecamp 3, they’re also available on the desktop versions for Mac and Windows, and on iOS (iPhone and iPad) and Android.We’re really proud of this new release, and we hope you find it especially useful. Goodbye === HACKS ===, hello GROUPS!All growing businesses run into the same fundamental problems. Hair on fire, buried under email, overwhelmed by chat, too many tools, stuff slips through the cracks, information spread everywhere. End all that with Basecamp 3. After switching to Basecamp 3, 89% of business owners report having a better handle on their business, and 84% report more self-sufficient teams. Get it all together in one place with a single system: Basecamp 3. Try it free today.New in Basecamp 3: To-do Groups was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


The Contrast Swap Technique: Improved Image Performance with CSS Filters

With CSS filter effects and blend modes, we can now leverage various techniques for styling images directly in the browser. However, creating aesthetic theming isn't all that filter effects are good for. You can use filters to indicate hover state, hide passwords, and now—for web performance.
While playing with profiling performance wins of using blend modes for duotone image effects (I'll write up an article on this soon), I discovered something even more exciting. A major image optimization win! The idea is to reduce image contrast in the source image, reducing its file size, then boosting the contrast back up with CSS filters!

Start with your image, then remove the contrast, and then reapply it with CSS filters.
How It Works
Let's put a point on exactly how this works:

Reduce image contrast using a linear transform function (Photoshop can do this)
Apply a contrast filter in CSS to the image to make up for the contrast removal

Step one involves opening your image in a program that lets you linearly reduce contrast in a linear way. Photoshop's legacy mode does a good job at this (Image > Adjustments > Brightness/Contrast):
You get to this screen via Image > Adjustments > Brightness/Contrast in Photoshop CC.
Not all programs use the same functions to apply image transforms (for example, this would not work with the macOS default image editor, since it uses a different technique to reduct contrast). A lot of the work done to build image effects into the browser was initially done by Adobe, so it makes sense that Photoshop's Legacy Mode aligns with browser image effects.
Then, we apply some CSS filters to our image. The filters we'll be using are contrast and (a little bit of) brightness. With the 50% Legacy Photoshop reduction, I applied filter: contrast(1.75) brightness(1.2); to each image.
Major Savings
This technique is very effective for reducing image size and therefore the overall weight of your page. In the following study, I used 4 vibrant photos taken on an iPhone, applied a 50% reduction in contrast using Photoshop Legacy Mode, saved each photo at Maximum quality (10), and then applied filter: contrast(1.75) brightness(1.2); to each image. These are the results:

You can play with the live demo here to check it out for yourself!
In each of the above cases, we saved between 23% and 28% in image size by reducing and reapplying the contrast using CSS filters. This is with saving each of the images at maximum quality.
If you look closely, you can see some legitimate losses in image quality. This is especially true with majority-dark images. so this technique is not perfect, but it definitely proves image savings in an interesting way.
Browser Support Considerations
Be aware that browser support for CSS filters is "pretty good".
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.DesktopChromeOperaFirefoxIEEdgeSafari18*15*35No166*Mobile / TabletiOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox6.0-6.1*37*No4.4*6156
As you can see, Internet Explorer and Opera Mini lack support. Edge 16 (the current latest version) supports CSS filters and this technique works like a charm. You'll have to decide if a reduced-contrast image as a fallback is acceptable or not.
What About Repainting?
You may be thinking: "but while we're saving in image size, we're putting more work on the browser, wouldn't this affect performance?" That's a great question! CSS filters do trigger a repaint because they set off window.getComputedStyle(). Let's profile our example.
What I did was open an incognito window in Chrome, disable JavaScript (just to be certain for the extensions I have), set the network to "Slow 3G" and set the CPU to a 6x slowdown:
With a 6x CPU slowdown, the longest Paint Raster took 0.27 ms, AKA 0.00027 seconds.
While the images took a while to load in, the actual repaint was pretty quick. With a 6x CPU slowdown, the longest individual Rasterize Paint took 0.27 ms, AKA 0.00027 seconds.
CSS filters originated from SVG filters, and are relatively browser optimized versions of the most popular SVG filter effect transformations. So I think its pretty safe to use as progressive enhancement at this point (being aware of IE users and Opera Mini users!).
Conclusion and the Future
There are still major savings to be had when reducing image quality (again, in this small study, the images were saved at high qualities for more of a balanced result). Running images through optimizers like ImageOptim, and sending smaller image file sizes based on screen sized (like responsive images in HTML or CSS) will give you even bigger savings.
In the web performance optimization world, I find image performance the most effective thing we can do to reduce web cruft and data for our users, since images are the largest chunk of what we send on the web (by far). If we can start leveraging modern CSS to help lift some of the weight of our images, we can look into a whole new world of optimization solutions.
For example, this could potentially be taken even further, playing with other CSS filters such as saturate and brightness. We could leverage automation tools like Gulp and Webpack to apply the image effects for us, just as we use automation tools to run our images through optimizers. Blending this technique with other best practices for image optimization, can lead to major savings in the pixel-based assets we're sending our users.

The Contrast Swap Technique: Improved Image Performance with CSS Filters is a post from CSS-Tricks
Source: CssTricks


Manage and Protect Your Apple Devices

(This is a sponsored post.)Jamf Now is a mobile device management solution for the iPad, iPhone, and Mac devices at work.
We make management tasks like deploying Wi-Fi passwords, setting up email accounts, securing company data, and enforcing passcodes, simple and affordable, so businesses can support their users. No IT required.
CSS-Tricks readers can manage their first 3 devices for free, forever! Sign up today to create your free account!

Direct Link to Article — Permalink
Manage and Protect Your Apple Devices is a post from CSS-Tricks
Source: CssTricks


What’s new in Basecamp 3.6 on iOS

This feature-packed release of Basecamp for iPhone and iPad is available in the App Store today. Here’s a look at what’s new.Improved attachments and sketchingIt all starts with a redesigned file picker. Tap the paperclip button anywhere in Basecamp to see clear buttons for each kind of thing you can attach. They’re all first-class — especially Sketch which got a big boost in this release. Now, before you upload an image to Basecamp you’ll have the option to draw on it first. It’s great for highlighting and making notes — or just having fun.Pick an image (left), tap ‘Sketch on image’, then add your drawings before uploading to Basecamp.In addition to sketching on images, we’ve also beefed-up the drawing tools. You can now choose the from 3 line weights and 5 colors to add variety and interest to your sketches. Also new: save your Basecamp sketches or share them to other apps.Works great with Apple Pencil on iPad Pro, too.Drag and Drop Files on iPadOne of the coolest new features on iOS 11 is drag and drop and it’s now supported in Basecamp. You can now select one (or more) images from the Photos app, for example, and simply drop them into Basecamp! Here’s how it looks:Drag one or multiple files into Basecamp.Easier invitesAwhile back, inviting people to your projects got easier with the introduction of special links you could send to people that would automatically invite them to the project — no need to enter their name and email. On iOS we took that a step further. With one tap you can now share the URL with others via Messages, Email, Airdrop — or any other apps you use on iOS. It’s the easiest way to get people into your projects yet!iOS 11 updatesFinally this release includes several fixes and improvements for iOS 11. The most notable one is for people who were unable to upload images to Basecamp because they were using iOS 11’s new space-saving HEIC format. Now when you upload an HEIC image, Basecamp will automatically convert it to a compatible format (jpg). It all happens automatically and behind-the-scenes so you won’t have to do a thing—it just works!That’s all for now. We’re cooking up more for the next release. Stay tuned!As always, please keep your suggestions, feedback, and bug reports coming our way. We’ve got some neat stuff coming in the next version so if you’re interesting in seeing it before everyone else, we have a few openings in our private beta. Send us an email and we’ll invite you.❤️ The iOS Team at Basecamp, Tara Mann, Dylan Ginsburg, Zach Waugh, and me.What’s new in Basecamp 3.6 on iOS was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


What’s new in Basecamp 3.5.4 for iOS

🍂 Fall is here, there’s a new version of iOS, and with it comes a new release to Basecamp for iPhone and iPad. It’s available in the App Store today. Here’s a brief look at what’s new:Quick jumpQuick jump is one of our favorite new things in Basecamp this year and we’re excited to bring it to iOS. It works exactly like the desktop version, especially on iPads with a keyboard attached (either 3rd party keyboards or iPad Pro with the Smart Keyboard). Command + J to start. Arrow up/down. Enter to select. Type to filter. It’s just the same.Quick jump to projects, people, or recently visited items.It’s also available on as an experimental feature on iPhone. That’s an atypical approach for us so let me explain. As of today you can quick jump by swiping from the top edge of your iOS device with two fingers. It works pretty well but the gesture makes this feature hard to find on your own, it can be difficult to execute reliably, it gets overridden by a system gesture used by iOS’s Voice Over, and until we hold one in our hands, we’re unsure how well this gesture will hold up on the iPhone X.Quick-jump on iPhone. Swipe-down with two fingers to access recent items. Type to filter.That said we’ve been using it internally for weeks so we know it’s useful. Rather than hold it back until we have a better idea, until we get it perfect, we made the decision to ship it and see how it fares in the wild. To be successful this feature needs to be quickly and easily available anywhere you are in the app and today the best means to accomplish that is with a gesture which can be triggered anytime. We hope with daily use and your feedback, new solutions will present themselves. We’ll continue to evaluate and evolve in upcoming releases.Rich text editingIn our previous release we added support for the new rich Color tool. This time we’ve kept pace by adding support for the new Horizontal Rule tool. We also reversed our decision to match the Basecamp desktop and remove the indent/outdent tools. While normally it makes sense to offer the same tools on all platforms, it’s the tab key that made indent/outdent expendable on desktop. Without a tab key on iOS (unless you have an external keyboard) we left users with no way to indent. This update brings them back.Horizontal Rule, Outdent/Indent.Keyboard ShortcutsIn addition to command + J to quick jump we’ve added shortcuts for quickly opening the Home, Hey!, Activity and Find tabs on iPad.Hold the command key to see available shortcuts on iPad.Finally we included a few fixes for issues with iOS 11.As always, please keep your suggestions, feedback, and found bugs coming our way. We’ve got some neat stuff coming in the next version so if you’re interesting in seeing them before everyone else, we have a few openings in our private beta. Send us an email for details.❤️ The iOS Team at Basecamp, Tara Mann, Dylan Ginsburg, Zach Waugh, and me.What’s new in Basecamp 3.5.4 for iOS was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


Designing Websites for iPhone X

We've already covered "The Notch" and the options for dealing with it from an HTML and CSS perspective. There is a bit more detail available now, straight from the horse's mouth:

Safe area insets are not a replacement for margins.
... we want to specify that our padding should be the default padding or the safe area inset, whichever is greater. This can be achieved with the brand-new CSS functions min() and max() which will be available in a future Safari Technology Preview release.
@supports(padding: max(0px)) {
.post {
padding-left: max(12px, constant(safe-area-inset-left));
padding-right: max(12px, constant(safe-area-inset-right));
}
}
It is important to use @supports to feature-detect min and max, because they are not supported everywhere, and due to CSS’s treatment of invalid variables, to not specify a variable inside your @supports query.

Jeremey Keith's hot takes have been especially tasty, like:

You could add a bunch of proprietary CSS that Apple just pulled out of their ass.
Or you could make sure to set a background colour on your body element.
I recommend the latter.

And:

This could be a one-word article: don’t.
More specifically, don’t design websites for any specific device.

Although if this pushes support forward for min() and max() as generic functions, that's cool.
Direct Link to Article — Permalink
Designing Websites for iPhone X is a post from CSS-Tricks
Source: CssTricks


“The Notch” and CSS

Apple's iPhone X has a screen that covers the entire face of the phone, save for a "notch" to make space for a camera and other various components. The result is some awkward situations for screen design, like constraining websites to a "safe area" and having white bars on the edges. It's not much of a trick to remove it though, a background-color on the body will do. Or, expand the website the whole area (notch be damned), you can add viewport-fit=cover to your meta viewport tag.
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">

Then it's on you to account for any overlapping that normally would have been handled by the safe area. There is some new CSS that helps you accommodate for that. Stephen Radford documents:

In order to handle any adjustment that may be required iOS 11's version of Safari includes some constants that can be used when viewport-fit=cover is being used.

safe-area-inset-top
safe-area-inset-right
safe-area-inset-left
safe-area-inset-bottom

This can be added to margin, padding, or absolute position values such a top or left.
I added the following to the main container on the website.
padding: constant(safe-area-inset-top) constant(safe-area-inset-right) constant(safe-area-inset-bottom) constant(safe-area-inset-left);

There is another awkward situation with the notch, the safe area, and fixed positioning. Darryl Pogue reports:

Where iOS 11 differs from earlier versions is that the webview content now respects the safe areas. This means that if you have a header bar that is a fixed position element with top: 0, it will initially render 20px below the top of the screen: aligned to the bottom of the status bar. As you scroll down, it will move up behind the status bar. As you scroll up, it will again fall down below the status bar (leaving an awkward gap where content shows through in the 20px gap).
You can see just how bad it is in this video clip:

Fortunately also an easy fix, as the viewport-fit=cover addition to the meta viewport tag fixes it.
If you're going to cover that viewport, it's likely you'll have to get a little clever to avoid hidden content!

I think I’ve fixed the notch issue in landscape 🍾 #iphoneX pic.twitter.com/hGytyO3DRV
— Vojta Stavik (@vojtastavik) September 13, 2017

“The Notch” and CSS is a post from CSS-Tricks
Source: CssTricks


Basecamp 3 for iOS: Hybrid Architecture

We’ve written quite a bit in the past about our approach to building hybrid mobile apps. Basecamp 3 represents the latest generation of this architecture, taking everything we’ve learned from previous versions.The first app for Basecamp 2 app was iPhone only, written in RubyMotion as a thin wrapper around UIWebView. Next, we did a new universal app for Basecamp 2, written in Xcode + Objective-C, still a using UIWebView, but with a bit more native code thrown in. For Basecamp 3, we’ve replaced Objective-C with Swift, UIWebView with WKWebView and added Turbolinks, with even more native code, and a deeper integration between native and web.Defining HybridFirst, it helps to be clear about what we mean by “hybrid”. That term is used in so many different contexts, that it’s almost meaningless. In our use, we’re referring to standard native apps where a significant portion of the content is rendered using web technology. I explicitly say content there because it is an important distinction. We’re not using a framework that attempts to mimic native controls using HTML/CSS. We’re not using a framework that tries to compile another language to native code, or make a cross-platform app from a single codebase.For us, it means using Xcode + Swift, and conforming to all the platforms conventions regarding navigation/presentation. The building blocks of our app are composed of UINavigationController, UITabViewController, UISplitViewController, UIViewController, etc. Within those containers, we have many screens where the content is built using UITableView or UICollectionView, we have even more where that role is filled by a WKWebView.Under the hoodBasecamp 3 for iOS is written 100% in Swift 3.1 (soon to be 4), using the latest version of Xcode. We only have a few dependencies, but the ones we do have we manage with Carthage. The core library for enabling this hybrid architecture is Turbolinks. We use Turbolinks on the web, and our companion frameworks for iOS and Android let us use it in our native apps as well. The framework handles communicating with Turbolinks.js and allowing the use of a single WKWebView, shared across multiple different screens.Router/NavigatorIn addition to Turbolinks, we have a number of other components to support it. Most of our navigation in the iOS app is URL-driven. A url can come from a number of sources (web link, push notification, universal link from another app, native action, etc), and they all go through the Router. This router is responsible for figuring out exactly what action to take for a given url. The router may open the url in Safari if it’s for another domain, display a media viewer if it’s an image/video, or in the common case, create a new view controller to display. The router hands off a view controller off to the Navigator which handles the presentation. Most view controllers are pushed on the current navigation stack, but we also support presenting certain screens (like new/edit views) modally, or replacing the current screen when appropriate.BridgeThe last component that makes up the hybrid architecture (though we have a number of other components not related to the hybrid part) is what we call the “Bridge”. This is a umbrella term for all the various parts of the app involved in native→web (or web→native) communication. The primary code here is a local JavaScript file (written in TypeScript) embedded in the app and injected into the web view using WKUserScript. This provides native code an API for communicating with the web view without needing to directly query the DOM or do complex JS. Using a WKScriptMessageHandler, we can respond to messages sent from the web view through the bridge.Bridge in action. The mobile web is on the left, the app is on the right. The bridge hides the top nav, breadcrumbs, and other elements we want render differently in the appAbove is one example of the bridge in action. We use it to hide many elements that are normally displayed on the mobile web that don’t make sense in the app. Since we provide a tab bar for top-level navigation, we don’t need that displayed here. Since we have a navigation controller, we don’t need the breadcrumbs for navigation. Finally, we hide the web edit/bookmark/actions menu and instead provide a native version.ExamplesThis is easier to visualize what this looks like in practice with a few examples. In the images below, I’ll use a purple overlay to indicate web view, and a green overlay to indicate native UI.Main TabsBasecamp 3 for iOS has 4 main tabs (Home, Hey!, Activity, and Find). Each one of these tabs are 100% native. These are the primary points of interaction in the app, and we wanted them to be as fast as possible. We also wanted to provide a different experience from the desktop that we thought made more sense on mobile, such as a unified Hey! for all notifications that also included recent Pings.Basecamp 3 for iOS — Main tabsMessageWhen you tap a notification in Hey!, say for a new message, then we push a new TurbolinksViewController on the navigation stack:From left to right: Hey! screen, viewing a message, actions menu, tools menuThis is a typical screen where all the content is a web view. Through our bridge, we pulled data out of the page to display in the navigation bar. Similarly, we used data from the DOM to populate a native actions menu popover displayed when you tap the “…” button. Since this dynamic and provided by the page, we can change it server-side at any time. Finally, if you tap the nav bar title, we show a native “tools menu” that provides quick access for navigating around a project.CampfireWe also have screens where the content is a mix of both native and web. This is the case for Campfires:From left to right: Hey! screen, viewing a campfire, completing a mention, attaching a fileThe main chat content here is web, but we decided to use a native view for the input. This fixes a number of issues with the web input like maintaining the correct position when scrolling, and we can also have better control over things like interactive keyboard dismissal. When typing someone’s name, we use a native mention auto-completer. Tapping the paperclip button shows the attachment picker, which is a native element that we use throughout the app with some nice touches, like quickly picking recently taken photos. All these components can work seamlessly together on the same screen.SummaryThose are just a few examples, but demonstrates the flexibility of this approach. The key to this architecture is that we’re not locked into one method or framework. Native or web isn’t a binary choice, but instead a spectrum:Web → Native spectrumFor each screen of the app, we can adjust where we sit on that spectrum. We can decide a native screen gets little use and isn’t worth the maintenance, so we change it to web. We can decide a web screen isn’t providing the best experience, and convert it to native. We could decide to try React Native and mix that in as well. Whenever Apple releases a new API, we can immediately support it since we’re not depending on a 3rd-party framework to be updated.One thing we deeply value at Basecamp is independence of teams. If we had to coordinate the integrationand release of every feature with the web, iOS, and Android teams all working in lockstep, we’d never ship anything. This architecture allows our web team to build a new feature and ship it simultaneously across all platforms. By default, we have a view controller that can display any url in Basecamp 3, so any new urls will just work in the app. We can iterate and experiment on the web, ship immediately on all platforms, and later make it native if feel we can improve the experience.This also lets us the mobile teams focus on how to best serve the platform. One of our goals is 100% coverage in the mobile apps, you should never have to go to the desktop because the apps don’t support something. With our solid foundation provided by the web, we can deliver on that goal, and then focus our efforts on platform-specific improvements. These include features like rich content push notifications, universal links, hand-off support, iCloud Keychain support, share extension, today widget, and more. Some of those things would be impossible or non-trivial if we didn’t have full native support at our disposal.Basecamp 3 for iOS: Hybrid Architecture was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


YouTube Users on iOS Can Now Live Stream Their Screens by @MattGSouthern

Google has updated its YouTube app for iOS with the ability to live stream iPhone or iPad screens.The post YouTube Users on iOS Can Now Live Stream Their Screens by @MattGSouthern appeared first on Search Engine Journal.
Source: https://www.searchenginejournal.com/feed/


Highrise 3.0 for iOS

For an app that’s been around since 2007, two iterations of its iOS app seems a bit on the light side. We agree. So today we have not just one announcement, but two:Highrise 3.0 for the iPhone is now available to everyone.It has the basics from before. Stay up to date on your team’s activity. Easily search your leads and quickly call, text, or get directions. Plan your day with tasks and follow-ups.And it has some important new features.Search leads by tag. View tags on contacts. See upcoming tasks when viewing a lead.Scroll through all of your tasks. Whether you have 2 or thousands of overdue or upcoming tasks… though we still can’t help you get them done. :)And more… like the ability to enter custom fields and choose from predefined values, dial incorrectly formatted international phone numbers, emoji, saved recent searches.Alas, it doesn’t have everything for everyone yet. Some will notice it doesn’t have Cases or Deals.But, our second announcement is that this is a whole rewrite of our mobile platform using C# and Microsoft’s Xamarin. This allows us to:update more frequentlyadd functionality easilyupdate it in parallel with our Android app. For those of you using the Android app from January, we have the same features headed your way soon!So we can get Deals and Cases added a lot easier now. Please stay tuned if that’s something you need. And if you want to hear more about our choice to use C# and Microsoft’s tools in our mobile development, here’s an interview with Michael Dwan our CTO.Here’s some feedback so far:Just Right (iankennedy) August 7, 2017 The perfect CRM for a small business with multiple offices. We use Highrise to coordinate several offices and hundreds of clients. The mobile app is great for entering quick notes or adding new contacts on the fly when out in the field. Take [conversation] out of email and put them in Highrisebody[data-twttr-rendered="true"] {background-color: transparent;}.twitter-tweet {margin: auto !important;}Lovin' the new @highrise iOS app! Great update! #CRM — @Dan_Agnewfunction notifyResize(height) {height = height ? height : document.documentElement.offsetHeight; var resized = false; if (window.donkey && donkey.resize) {donkey.resize(height); resized = true;}if (parent && parent._resizeIframe) {var obj = {iframe: window.frameElement, height: height}; parent._resizeIframe(obj); resized = true;}if (window.location && window.location.hash === "#amp=1" && window.parent && window.parent.postMessage) {window.parent.postMessage({sentinel: "amp", type: "embed-size", height: height}, "*");}if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.resize) {window.webkit.messageHandlers.resize.postMessage(height); resized = true;}return resized;}twttr.events.bind('rendered', function (event) {notifyResize();}); twttr.events.bind('resize', function (event) {notifyResize();});if (parent && parent._resizeIframe) {var maxWidth = parseInt(window.frameElement.getAttribute("width")); if ( 500 < maxWidth) {window.frameElement.setAttribute("width", "500");}}body[data-twttr-rendered="true"] {background-color: transparent;}.twitter-tweet {margin: auto !important;}The iOS update to @highrise is a huge jump forward. Hope that it allows them to roll out other improvements. — @sphfunction notifyResize(height) {height = height ? height : document.documentElement.offsetHeight; var resized = false; if (window.donkey && donkey.resize) {donkey.resize(height); resized = true;}if (parent && parent._resizeIframe) {var obj = {iframe: window.frameElement, height: height}; parent._resizeIframe(obj); resized = true;}if (window.location && window.location.hash === "#amp=1" && window.parent && window.parent.postMessage) {window.parent.postMessage({sentinel: "amp", type: "embed-size", height: height}, "*");}if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.resize) {window.webkit.messageHandlers.resize.postMessage(height); resized = true;}return resized;}twttr.events.bind('rendered', function (event) {notifyResize();}); twttr.events.bind('resize', function (event) {notifyResize();});if (parent && parent._resizeIframe) {var maxWidth = parseInt(window.frameElement.getAttribute("width")); if ( 500 < maxWidth) {window.frameElement.setAttribute("width", "500");}}If you enjoy it, we’d greatly appreciate a review on the App Store, and if you have any issues or feedback, there’s a Help & Feedback button in the app to send us your info.Download Highrise 3.0 for the iPhone.Highrise 3.0 for iOS was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals


Reasons to Build Your Own App

I’m working on a very small To-Do iOS app and I’m sharing my process and my thoughts candidly through the process in a new YouTube playlist affectionately titled “Let’s Build an App“.
As you already know, I’m heavily involved with my startup and that’s where 99% of my time goes, but, in the 1% I’m sloooooooooowly putting this thing together.

And, for the first time ever, I have a new medium through which I can share the process which is my YouTube channel.
Although I’ve been pretty candid and honest historically about these indie projects, I’ve always done it through blog posts and not through any video content.
So, in that way, I’m having a good time with it and it’s a bit of a different feel, which is something that keeps it fresh for me. These are truly candid captures of my thoughts and there’s no established framework of my thoughts. It’s rough, off-the-cuff, and fairly disorganized, but, it captures authentically the process for these side projects, that’s for sure.
Today, I shared a few thoughts on why one might put together yet-another-app, especially a To-Do List app that’s been done 1,000,000 times (and counting).

I’ve listed them out here for you as well:

Design – I may simply not like the design of existing apps and for that reason I want to put together one that’s better designed.
Simplicity – The apps that are currently available are far too complex for my own taste. I’m in the business of creating super-simple, almost single-serve type of apps. This is my own integrationpreference, by the way, especially for smaller projects like these.
Focused Utility – Very much similar to #2, I just want to be able to solve a single and specific problem area, not much more than that. This will help me understand if I’m really solving the problem or only hitting surface-level results.
Name – Perhaps I don’t like the names of existing apps. Yes, this is highly superficial, but, it’s a real emotional trigger.
Brand – Sometimes, for whatever reason, you just don’t like the brand of the product. It is what it is.
Accessibility – There are some very legitimate reasons why you need engagement in one system and not in the other (or that you need them in multiple locations). For instance, some people only want certain types of apps available on their Apple Watch while others want it on that and the iPhone (and iPad).
Because It’s Not Mine – Sometimes you just want to build your own and that’s the driving force behind you spending any time on the project. It might just be the very thing that gets you to start building in the first place.

Knowing my own behavior over the years I know that I have always first tried to solve my own problems and secondly tried to keep things as simple as humanly possible.
The To-Do list app is almost an exercise for my own self in those two principles and I’m enjoying the challenge of thinking through it when I have the time.
The post Reasons to Build Your Own App appeared first on John Saddington.
Source: https://john.do/


Aziz Ansari

This is some of the smartest stuff that Aziz has ever said (or at least the stuff that I’ve heard him speak about):

He’s off social media. He deleted the Internet browser from his phone and laptop. No e-mail, either. Technologically speaking, he’s living in, like, 1999.
Really…? As the writer ponders, did he unplug or “unplug”?
Whenever you check for a new post on Instagram or whenever you go on The New York Times to see if there’s a new thing, it’s not even about the content. It’s just about seeing a new thing. You get addicted to that feeling. You’re not going to be able to control yourself. So the only way to fight that is to take yourself out of the equation and remove all these things.
So, he has removed them. Entirely. He continues:
What happens is, eventually you forget about it. You don’t care anymore. When I first took the browser off my phone, I’m like, [gasp] How am I gonna look stuff up? But most of the shit you look up, it’s not stuff you need to know. All those websites you read while you’re in a cab, you don’t need to look at any of that stuff. It’s better to just sit and be in your own head for a minute.
Man, I love that. The result? Less toxicity in his life:
So if you take yourself out of it, you’re not infected with this toxicity all the time. Also, guess what? Everything is fine! I’m not out of the loop on anything. Like, if something real is going down, I’ll find out about it.
I can dig that, 100%. And, this was personally very challenging. As a result, I’ve removed more than a few apps from my own phone, like Reddit which is a total time suck.
And so this is going to be the beginning of an interesting experiment. I’m going to go through my phone and remove a ton of apps, many of which are useful but not necessary. The line in the sand between these two can be fuzzy, I’ll admit, but, already I’m seeing some nice results.
It’s also worth noting that I experimented with an idea of not checking anything on my ride back from San Jose on the Caltrain for 90+ minutes. The idea here was to go into “deep thinking” instead of the candy that is my iPhone and the many apps and news outlets that I could be reading.
The results were very positive and that was enough kick for me to expand the experiment quite a bit. I may report back in a bit but this is in line with my paring down much of my life and social engagement and just focusing on what really matters.
I love that.
The post Aziz Ansari appeared first on John Saddington.
Source: https://john.do/


Let’s Talk About Speech CSS

Boston, like many large cities, has a subway system. Commuters on it are accustomed to hearing regular public address announcements.
Riders simply tune out some announcements, such as the pre-recorded station stop names repeated over and over. Or public service announcements from local politicians and celebrities—again, kind of repetitive and not worth paying attention to after the first time. Most important are service alerts, which typically deliver direct and immediate information riders need to take action on.

An informal priority
A regular rider's ear gets trained to listen for important announcements, passively, while fiddling around on a phone or zoning out after a hard day of work. It's not a perfect system—occasionally I'll find myself trapped on a train that's been pressed into express service.
But we shouldn't remove lower priority announcements. It's unclear what kind of information will be important to whom: tourists, new residents, or visiting friends and family, to name a few.
A little thought experiment: Could this priority be more formalized via sound design? The idea would be to use different voices consistently or to prefix certain announcements with specific tones. I've noticed an emergent behavior from the train operators that kind of mimics this: Sometimes they'll use a short blast of radio static to get riders' attention before an announcement.
Opportunities
I've been wondering if this kind of thinking can be extended to craft better web experiences for everyone. After all, sound is enjoying a renaissance on the web: the Web Audio API has great support, and most major operating systems now ship with built-in narration tools. Digital assistants such as Siri are near-ubiquitous, and podcasts and audiobooks are a normal part of people's media diet.
Deep in CSS'—ahem—labyrinthine documentation, are references to two Media Types that speak to the problem: aural and speech. The core idea is pretty simple: audio-oriented CSS tells a digitized voice how it should read content, the same as how regular CSS tells the browser how to visually display content. Of the two, aural has been deprecated. speech Media Type detection is also tricky, as a screen reader potentially may not communicate its presence to the browser.
The CSS 3 Speech Module, the evolved version of the aural Media Type, looks the most promising. Like display: none;, it is part of the small subset of CSS that has an impact on screen reader behavior. It uses traditional CSS property/value pairings alongside existing declarations to create an audio experience that has parity with the visual box model.
code {
background-color: #292a2b;
color: #e6e6e6;
font-family: monospace;
speak: literal-punctuation; /* Reads all punctuation out loud in iOS VoiceOver */
}
Just because you can, doesn't mean you should
In his book Building Accessible Websites, published in 2003, author/journalist/accessibility researcher Joe Clark outlines some solid reasons for never altering the way spoken audio is generated. Of note:
Support
Many browsers don't honor the technology, so writing the code would be a waste of effort. Simple and direct.
Proficiency
Clark argues that developers shouldn't mess with the way spoken content is read because they lack training to "craft computer voices, position them in three-dimensional space, and specify background music and tones for special components."
This may be the case for some, but ours is an industry of polymaths. I've known plenty of engineers who develop enterprise-scale technical architecture by day and compose music by night. There's also the fact that we've kind of already done it.
The point he's driving at—crafting an all-consuming audio experience is an impossible task—is true. But the situation has changed. An entire audio universe doesn't need to be created from whole cloth any more. Digitized voices are now supplied by most operating systems, and the number of inexpensive/free stock sound and sound editing resources is near-overwhelming.
Appropriateness
For users of screen readers, the reader's voice is their interface for the web. As a result, users can be very passionate about their screen reader's voice. In this light, Clark argues for not changing how a screen reader sounds out content that is not in its dictionary.
Screen readers have highly considered defaults for handling digital interfaces, and probably tackle content types many developers would not even think to consider. For example, certain screen readers use specialized sound cues to signal behaviors. NVDA uses a series of tones to communicate an active progress bar:

[soundcloud url="https://api.soundcloud.com/tracks/329553369" params="color=ff5500" width="100%" height="166" iframe="true" /]

Altering screen reader behavior effectively alters the user's expected experience. Sudden, unannounced changes can be highly disorienting and can be met with fear, anger, and confusion.
A good parallel would be if developers were to change how a mouse scrolls and clicks on a per-website basis. This type of unpredictability is not a case of annoying someone, it's a case of inadvertently rendering content more difficult to understand or changing default operation to something unfamiliar.
My voice is not your voice
A screen reader's voice is typically tied to the region and language preference set in the operating system.
For example, iOS contains a setting for not just for English, but for variations that include United Kingdom, Ireland, Singapore, New Zealand and five others. A user picking UK English will, among other things, find their Invert Colors feature renamed to "Invert Colours."
However, a user's language preference setting may not be their primary language, the language of their country of origin, or the language of the country they're currently living in. My favorite example is my American friend who set the voice on his iPhone to UK English to make Siri sound more like a butler.
UK English is also an excellent reminder that regional differences are a point of consideration, y'all.
Another consideration is biological and environmental hearing loss. It can manifest with a spectrum of severity, so the voice-balance property may have the potential to "move" the voice outside of someone's audible range.
Also, the speed the voice reads out content may be too fast for some or too slow for others. Experienced screen reader operators may speed up the rate of speech, much as some users quickly scroll a page to locate information they need. A user new to screen readers, or a user reading about an unfamiliar topic may desire a slower speaking rate to keep from getting overwhelmed.
And yet
Clark admits that some of his objections exist only in the realm of the academic. He cites the case of a technologically savvy blind user who uses the power of CSS' interoperability to make his reading experience pleasant.
According to my (passable) research skills, not much work has been done in asking screen reader users their preferences for this sort of technology in the fourteen years since the book was published. It's also important to remember that screen reader users aren't necessarily blind, nor are they necessarily technologically illiterate.
The idea here would be to treat CSS audio manipulation as something a user can opt into, either globally or on a per-site basis. Think web extensions like Greasemonkey/Tampermonkey, or when websites ask permission to send notifications. It could be as simple as the kinds of preference toggles users are already used to interacting with:
A fake screenshot simulating a preference in NVDA that would allow the user to enable or disable CSS audio manipulation.
There is already a precedent for this. Accessibility Engineer Léonie Watson notes that JAWS—another popular screen reader—“has a built in sound scheme that enables different voices for different parts of web pages. This suggests that perhaps there is some interest in enlivening the audio experience for screen reader users.”
Opt-in also supposes features such as whitelists to prevent potential abuses of CSS-manipulated speech. For example, a user could only allow certain sites with CSS-manipulated content to be read, or block things like unsavory ad networks who use less-than-scrupulous practices to get attention.
Opinions: I have a few
In certain situations a screen reader can't know the context of content but can accept a human-authored suggestion on how to correctly parse it. For example, James Craig's 2011 WWDC video outlines using speak-as values to make street names and code read accurately (starts at the 15:36 mark, requires Safari to view).
In programming, every symbol counts. Being able to confidently state the relationship between things in code is a foundational aspect of programming. The case of thisOne != thisOtherOne being read as "this one is equal to this other one" when the intent was "this one is not equal to this other one" is an especially compelling concern.
Off the top of my head, other examples where this kind of audio manipulation would be desirable are:

Ensuring names are pronounced properly.
Muting pronunciation of icons (especially icons made with web fonts) in situations where the developer can't edit the HTML.
Using sound effect cues for interactive components that the screen reader lacks built-in behaviors for.
Creating a cloud-synced service that stores a user's personal collection of voice preferences and pronunciation substitutions.
Ability to set a companion voice to read specialized content such as transcribed interviews or code examples.
Emoting. Until we get something approaching EmotionML support, this could be a good way to approximate the emotive intent of the author (No, emoji don't count).
Spicing things up. If a user can't view a website's art direction, their experience relies on the skill of the writer or sound editor—on the internet this can sometimes leave a lot to be desired.

The reality of the situation
The CSS Speech Module document was last modified in March 2012. VoiceOver on iOS implements support using the following speak-as values for the speak property, as shown in this demo by accessibility consultant Paul J. Adam:

normal
digits
literal-punctuation
spell-out

Apparently, the iOS accessibility features Speak Selection and Speak Screen currently do not honor these properties.
Despite the fact that CSS 3 Speech Module has to be ratified (and therefore is still subject to change), VoiceOver support signals that a de facto standard has been established. The popularity of iOS—millions of devices, 76% of which run the latest version of iOS—makes implementation worth considering. For those who would benefit from the clarity provided by these declarations, it could potentially make a big difference.
Be inclusive, be explicit
Play to CSS' strengths and make small, surgical tweaks to website content to enhance the overall user experience, regardless of device or usage context. Start with semantic markup and a Progressive Enhancement mindset. Don't override pre-existing audio cues for the sake of vanity. Use iOS-supported speak-as values to provide clarity where VoiceOver's defaults need an informed suggestion.
Writing small utility classes and applying them to semantically neutral span tags wrapped around troublesome content would be a good approach. Here's a recording of VoiceOver reading this CodePen to demonstrate:

Take care to extensively test to make sure these tweaks don't impair other screen reading software. If you're not already testing with screen readers, there's no time like the present to get started!
Unfortunately, current support for CSS speech is limited. But learning what it can and can't do, and the situations in which it could be used is still vital for developers. Thoughtful and well-considered application of CSS is a key part of creating robust interfaces for all users, regardless of their ability or circumstance.

Let’s Talk About Speech CSS is a post from CSS-Tricks
Source: CssTricks


What’s new in Basecamp for iOS

Basecamp 3.5.1 is now available in the App Store. If you’re already a pro with Basecamp on your iPhone and iPad, you’re going to love this release. If you haven’t tried it yet, now is a great time to start taking advantage of these new time-saving features. While you’re installing the latest update, read this quick look at what’s new…Swipe for your next unreadWhen you’ve got a bunch of unreads on Hey! and you’re cranking through them, it can feel like a chore to tap an unread, read it, then go back and tap the next one. Now you can simply tap an unread and when you’re done reading it, swipe-left to go to the next one! Repeat until you’re done. Here’s how it looks:1. Tap an unread, 2. Tap OK, 3. Swipe-left to load the next one!Search inside BasecampYou probably already know you can swipe-down or swipe-left from the Home screen on your iOS device to search for apps, contacts, events, emails, messages, etc. Now Basecamp Projects, Teams and People also appear in these results. Want to Ping Mark? Just type his name into iOS Search to jump right to his profile card. It’s nice time-saver and handy shortcut to launching Basecamp right to the place you want to go.Find someone in Basecamp and jump right to their profile. You can also search for Projects and Teams to reach them directly.My ScheduleIt’s new on your Home tab in Basecamp under My Stuff. See everything scheduled for you across all of your projects and teams in one place. You can also see this on the iOS Search screen when you enable the Basecamp widget that’s already installed if you have the Basecamp app.My schedule across all projects. Also available in the iOS Widget.Support for iOS 11If you’re running a integrationbuild of iOS 11 or joined the just announced public beta, this release fixes a few issues we discovered. While we can’t offer full support for an unreleased version of iOS, we do our best to keep things working smoothly if at all possible.Basecamp 3 for iOS is made by me, Dylan Ginsburg, Tara Mann, Zach Waugh and the rest of the team at Basecamp. It’s also available on Android, Mac, and Windows — anywhere you’ve got a web browser and an internet connection. You can try Basecamp free for 30 days, it just takes just a minute to sign-up.What’s new in Basecamp for iOS was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.


Source: 37signals