Jeremy Keith's Blog, page 34

Curating UX London 2022

The first speakers are live on the UX London 2022 site! There are only five people announced for now���just enough to give you a flavour of what to expect. There will be many, many more.

Putting together the line-up of a three-day event is quite challenging, but kind of fun too. On the one hand, each day should be able to stand alone. After all, there are one-day tickets available. On the other hand, it should feel like one cohesive conference, not three separate events.

I���ve decided to structure the three days to somewhat mimic the design process…

The first day is all about planning and preparation. This is like the first diamond in the double-diamond process: building the right thing. That means plenty of emphasis on research.

The second day is about creation and execution. It���s like that second diamond: building the thing right. This could cover potentially everything but this year the focus will be on content design.

The third day is like the third diamond in the double dia— no, wait. The third day is about growing, scaling, and maintaining design. That means there���ll be quite an emphasis on topics like design systems and design engineering, maybe design ops.

But none of the days will be exclusively about a single topic. There are evergreen topics that apply throughout the process: product design, design ethics, inclusive design.

It���s a lot to juggle! But I���m managing to overcome choice paralysis and assemble a very exciting line-up indeed. Trust me���you won���t want to miss this!

Early bird tickets are available until February 28th. That���s just a few days away. I recommend getting your tickets now���you won���t regret it!

Quite a few people are bringing their entire teams, which is perfect. UX London can be both an educational experience and a team-bonding exercise. Let���s face it, it���s been too long since any of us have had a good off-site.

If you���re one of those lucky people who���s coming along (or if you���re planning to), I���m curious: given the themes mentioned above, are there specific topics that you���d hope to see covered? Drop me a line and let me know.

Also, if you read the description of the event and think ���Oh, I know the perfect speaker!��� then I���d love to hear from you. Maybe that speaker is you. (Although, cards on the table; if you look like me���another middle-age white man���I may take some convincing.)

Right. Time to get back to my crazy wall of conference curation.

02022-02-22

Eleven years ago, I made a prediction:

The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.

One year later, Matt called me on it and the prediction officially became a bet:

We���re playing for $1000. If I win, that money goes to the Bletchley Park Trust. If Matt wins, it goes to The Internet Archive.

I���m very happy to lose this bet.

When I made the original prediction eleven years ago that a URL on the longbets.org site would no longer be available, I did so in a spirit of mischief���it was a deliberately meta move. But it was also informed by a genuine feeling of pessimism around the longevity of links on the web. While that pessimism was misplaced in this case, it was informed by data.

The lifetime of a URL on the web remains shockingly short. What I think has changed in the intervening years is that people may have become more accustomed to the situation. People used to say ���once something is online it���s there forever!���, which infuriated me because the real problem is the exact opposite: if you put something online, you have to put in real effort to keep it online. After all, we don���t really buy domain names; we just rent them. And if you publish on somebody else���s domain, you���re at their mercy: Geocities, MySpace, Facebook, Medium, Twitter.

These days my view towards the longevity of online content has landed somewhere in the middle of the two dangers. There���s a kind of Murphy���s Law around data online: anything that you hope will stick around will probably disappear and anything that you hope will disappear will probably stick around.

One huge change in the last eleven years that I didn���t anticipate is the migration of websites to HTTPS. The original URL of the prediction used HTTP. I���m glad to see that original URL now redirects to a more secure protocol. Just like most of the World Wide Web. I think we can thank Let���s Encrypt for that. But I think we can also thank Edward Snowden. We are no longer as innocent as we were eleven years ago.

I think if I could tell my past self that most of the web would using HTTPS by 2022, my past self would be very surprised …���though not as surprised at discovering that time travel had also apparently been invented.

The Internet Archive has also been a game-changer for digital preservation. While it���s less than ideal that something isn���t reachable at its original URL, knowing that there���s probably a copy of the content at archive.org lessens the sting considerably. I couldn���t be happier that this fine institution is the recipient of the stakes of this bet.

Announcing UX London 2022

For the past two years, all of Clearleft���s events have been online. Like everyone else running conferences, we had to pivot in the face of The Situation.

In hindsight, it���s remarkable how well those online events went. This was new territory for everyone���speakers, attendees, and organisers.

UX Fest was a real highlight. I had the pleasure of hosting the event, giving it my Woganesque best. It was hard work, but it paid off.

Still, it���s not quite the same as gathering together with your peers in one place for a shared collective experience. I���ve really been missing in-person events (and from what I���ve seen in people���s end-of-year blog posts, I���m not alone).

That���s why I���m absolutely thrilled that UX London is back in 2022! Save the dates; June 28th to 30th. We���ve got a new venue too: the supremely cool Tobacco Dock.

This is going to be a summertime festival of design. It���ll be thought-provoking, practical, fun, and above all, safe.

It feels kind of weird to be planning an in-person event now, when we���re just emerging from The Omicron Variant, but putting on UX London 2022 isn���t just an act of optimism. It���s a calculated move. While nothing is certain, late June 2022 should be the perfect time to safely gather the UX community again.

It���s a particularly exciting event for me. Not only will I be hosting it, this time I���m also curating the line-up.

I���ve curated conference line-ups before: dConstruct, Responsive Day Out, and Patterns Day. But those were all one-day events. UX London is three times as big!

It���s a lot of pressure, but I���m already extremely excited about the line-up. If my plan comes together, this is going to be an unmissable collection of mindbombs. I���ve already got some speakers confirmed so keep an eye on the website, Twitter or sign up for the newsletter to get the announcements as when they happen.

The format of UX London has been honed over the years. I think it���s got just the right balance.

Each day has a morning of inspiring talks���a mixture of big-picture keynotes and punchy shorter case studies. The talks are all on a single track; everyone shares that experience. Then, after lunch, there���s an afternoon of half-day workshops. Those happen in parallel, so you choose which workshop you want to attend.

I think this mixture of the inspirational and the practical is the perfect blend. Your boss can send you to UX London knowing that you���re going to learn valuable new skills, but you���ll also leave with your mind expanded by new ideas.

Like I said, I���m excited!

Naturally, I���m nervous too. Putting on an event is a risky endeavour at the best times. Putting an event after a two-year pandemic is even more uncertain. What if no one comes? Maybe people aren���t ready to return to in-person events. But I can equally imagine the opposite situation. Maybe people are craving a community gathering after two years of sitting in front of screens. That���s definitely how I���m feeling.

If you���re feeling the same, then join me in London in June. Tickets are on sale now. You can get three-day early-bird pass, or you can buy a ticket for an individual day. But I hope you���ll join me for the whole event���I can���t wait to see you there!

Fonts or food?

At the end of every Thursday afternoon at Clearleft, we wrap up the working week with an all-hands (video) meeting. Yes, I know that the week finishes on Friday, but Fridays have been declared the no-meetings day at Clearleft: a chance to concentrate on heads-down work without interruption. Besides, some of us don���t work on Fridays. So Thursday really is the new Friday.

At this Thursday afternoon meeting we give and get updates on what���s been happening with project work, new business, events, marketing. We also highlighted any shout-outs that have posted in the #beingsplendid Slack channel during the week. Once that���s all taken care of, the Thursday afternoon meeting often finishes with a fun activity.

The hosting of the Thursday afternoon meeting is decided by fate. Two weeks ago, Rebecca and Chris hosted an excellent end-of-week meeting that finished with an activity around food���everyone had submitted their dream meal and we had to match up the meal to the person. Lorenzo, however, couldn���t help commenting on the typography in the slide deck. ���Lorenzo”, I said, ���What are you more judgmental about���fonts or food?���

The words were barely out of my mouth when I realised I had the perfect activity for the next Thursday afternoon meeting, which fate had decreed I was to host. I put together a quiz called ���fonts or food!

It���s quite straightforward. There are 25 words. All you have to do is say whether it���s the name of a font or the name of a food.

It was good fun! So I thought I���d share it with you if you fancy a go.

Ready?

Here we go���

Arrowroot font foodEnsete font foodTahu font foodTako font foodLato font foodFira font foodAdzuki font foodRoselle font foodPoke font foodPlantin font foodDabberlocks font foodEstampa font foodAmaranth font foodGentium font foodChallum font foodMayhaw font foodPawpaw font foodNopal font foodRaksana font foodDaylily font foodBilanthy font foodLaver font foodOrache font foodBroadley font foodCardoon font food

Total: 0/25

#fontsorfood li { display: table-row; } #fontsorfood li > * { display: table-cell; padding: 0.5em 1em; } #fontsorfood [data-result = "right"]::after { content: 'correct!'; } #fontsorfood [data-result = "wrong"]::after { content: 'incorrect'; }

document.getElementById('fontsorfood').querySelectorAll('input').forEach( el => { el.addEventListener('change', function(ev) { var item = el.closest('li'); if (item.dataset.answer == el.value) { item.dataset.result = 'right'; } else { item.dataset.result = 'wrong'; } item.querySelectorAll('input[type="radio"]').forEach( input => { input.setAttribute('disabled', 'disabled'); }); document.getElementById('fontsorfoodtotal').value = document.getElementById('fontsorfood').querySelectorAll('[data-result="right"]').length; });});

2.5.6

The Competition and Markets Authority (CMA) recently published an interim report on their mobile ecosystems market study. It���s well worth reading, especially the section on competition in the supply of mobile browsers:

On iOS devices, Apple bans the use of alternative browser engines ��� this means that Apple has a monopoly over the supply of browser engines on iOS. It also chooses not to implement ��� or substantially delays ��� a wide range of features in its browser engine. This restriction has 2 main effects:

limiting rival browsers��� ability to differentiate themselves from Safari on factors such as speed and functionality, meaning that Safari faces less competition from other browsers than it otherwise could do; and limiting the functionality of web apps ��� which could be an alternative to native apps as a means for mobile device users to access online content ��� and thereby limits the constraint from web apps on native apps. We have not seen compelling evidence that suggests Apple���s ban on alternative browser engines is justified on security grounds.

That last sentence is a wonderful example of British understatement. Far from protecting end users from security exploits, Apple have exposed everyone on iOS to all of the security issues of Apple���s Safari browser (regardless of what brower the user thinks they are using).

The CMA are soliciting responses to their interim report:

To respond to this consultation, please email or post your submission to:

Email: mobileecosystems@cma.gov.uk

Post: ���

Mobile Ecosystems Market Study
Competition and Markets Authority
���25 Cabot Square
���London
���E14 4QZ

Please respond by no later than 5pm GMT on 7 February 2022.

I encourage you to send a response before this coming Monday. This is the email I���ve sent.

Hello,

This response is regarding competition in the supply of mobile browsers and contains no confidential information.

I read your interim report with great interest.

As a web developer and the co-founder of a digital design agency, I could cite many reasons why Apple���s moratorium on rival browser engines is bad for business. But the main reason I am writing to you is as a consumer and a user of Apple���s products.

I own two Apple computing devices: a laptop and a phone. On both devices, I can install apps from Apple���s App Store. But on my laptop I also have the option to download and install an application from elsewhere. I can���t do this on my phone. That would be fine if my needs were met by what���s available in the app store. But clause 2.5.6 of Apple���s app store policy restricts what is available to me as a consumer.

On my laptop I can download and install Mozilla���s Firefox or Google���s Chrome browsers. On my phone, I can install something called Firefox and something called Chrome. But under the hood, they are little more than skinned versions of Safari. I���m only aware of this because I���m au fait with the situation. Most of my fellow consumers have no idea that when they install the app called Firefox or the app called Chrome from the app store on their phone, they are being deceived.

It is this deception that bothers me most.

Kind regards,

Jeremy Keith

To be fair to Apple, this deception requires collusion from Mozilla, Google, Microsoft, and other browser makers. Nobody���s putting a gun to their heads and forcing them to ship skinned versions of Safari that bear only cosmetic resemblance to their actual products.

But of course it would be commercially unwise to forego the app store as a distrubution channel, even if the only features they can ship are superficial ones like bookmark syncing.

Still, imagine what would happen if Mozilla, Google, and Microsoft put their monies where their mouths are. Instead of just complaining about the unjust situation, what if they actually took the financial hit and pulled their faux-browsers from the iOS app store?

If this unjustice is as important as representatives from Google, Microsoft, and Mozilla claim it is, then righteous indignation isn���t enough. Principles without sacrifice are easy.

If nothing else, it would throw the real situation into light and clear up the misconception that there is any browser choice on iOS.

I know it���s not going to happen. I also know I���m being a hypocrite by continuing to use Apple products in spite of the blatant misuse of monopoly power on display. But still, I wanted to plant that seed. What if Microsoft, Google, and Mozilla were the ones who walk away from Omelas.

Screenshots

I wrote about how I created a page on The Session with instructions for installing the site to your home screen. When I said that I included screenshots on that page, I may have underplayed the effort involved. It was real faff.

I���ve got an iPhone so generating screenshots (and video) from that wasn���t too bad. But I don���t have access to an Android phone. I found myself scouring the web for templates that I could use to mockup a screenshot of the address bar.

That got me thinking…

Wouldn���t it be cool if there were a service that generated those screenshots for you? You give it a URL, and it spits out screenshots of the site complete with overlays showing the installation flow on Android and iOS. It could even generate the img markup, complete with differently-scaled images for the srcset attribute.

Download the images. Copy that markup. Paste it into a page on your site. Boom! Now you���ve got somewhere to point your visitors to if you���d like them to install your progressive web app.

There are already some services out there for generating screenshots of mobile phones but they���re missing is the menu overlays for adding to home screen.

The devrels at both Google and Microsoft have been doing a great job of promoting progressive web apps. They���ve built tools to help you with tasks like generating icons or creating your web app manifest. It would be sooooo nifty if those tools also generated instructional screenshots for adding to home screen!

Installing progressive web apps

I don���t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don���t play the game myself, I think it���s pretty great.

Not only does Wordle have a very sweet backstory, but it���s also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That���s it. No need to download an app.

That hasn���t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.

Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don���t believe it has offline support). That���s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.

Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it���s great to see this knowledge being spread. On the other hand it���s dispiriting that it���s even necessary to tell people that they can do this, like it���s a hidden nerdy secret just for power users.

At this point I���ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?

Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.

That���s what I���ve done on thesession.org. I���ve published a page on how to install The Session to your home screen.

On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon���three vertical dots. On iOS you must first tap on the unlabeled share icon���a square with an arrow coming out of it.

When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.

I���ve included screenshots to help people identify these mysterious portals. For iOS I���ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.

I���ve linked to the page with the installation instructions from the site���s ���help��� page and the home page.

Handy tip: when you���re adding a start_url value to your web app manifest, it���s common to include a query string like this:

start_url: "/?homescreen"

I���m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don���t do analytics on The Session but I���m still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don���t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn���t see that message when they launch The Session.

If you���ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site���s visitors. You���d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.

Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there���s an emoji you could potentially use: ����

It���s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.

(I���m not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)

Partnering with Google on web.dev

When the web.dev team at Google contacted Clearleft about writing a course on responsive design, our eyes lit up.

This was clearly a good fit. For one thing, Clearleft has been pioneering responsive design from day one���we helped launch some of the first responsive sites in the UK. But there was another reason why this partnership sounded good: we had the same approach to writing and sharing.

Ever since Clearleft was founded in 2005 we���ve taken on board the motto of the World Wide Web itself: let���s share what we know. As well as doing the work, we enjoy sharing how the work gets done. Whether it���s case studies, blog posts, podcasts, or conference talks, we���re always thinking about ways to contribute to the web community.

Many other great resources have contributed to our collective knowledge: A List Apart, CSS Tricks, Smashing Magazine, Mozilla Developer Network, and more recently web.dev, which has become an excellent resource for front-end developers. But they wanted to make sure that designers were also included. Una described her plan for a fifteen-part course on modern responsive design aimed at web designers.

It was ambitious. The plan included some cutting edge technology that���s just shipping in browsers now. It sounded daunting and exciting in equal measure. Mostly it sounded like far too good an opportunity for Clearleft to pass up so we jumped on it.

With my fellow Clearlefties otherwise engaged in client work, it fell to me to tap out the actual words. Fortunately I���ve had plenty of experience with my own website of moving my fingers up and down on a keyboard in attempt to get concepts out of my head and onto the screen. I familiarised myself with the house style and got to work.

I had lots of help from the Chrome developer relations team at Google. Project management (thanks, Terry!), technical editing (thanks, Adam!), and copy editing (thanks, Rachel!) were provided to me.

Working with Rachel again was a real treat���she wrote the second edition of my book, HTML5 For Web Designers. Every time she suggested a change to something I had written, I found myself slapping my forehead and saying ���Of course! That���s so much better!��� It felt great to have someone else be a content buddy for me.

We had a weekly video call to check in and make sure everything was on track. There was also an epic spreadsheet to track the flow of each module as they progressed from outline to first draft to second draft.

Those were just the stages when the words were in a Google doc. After that, the content moved to Github and there was a whole other process to shepherd it towards going live.

Take note of the license in that repo: Creative Commons Attribution 3.0. That means that you���or anyone���is free to use and reuse all the material (as long as you include a credit). I think I might republish the fifteen articles on my site at some point.

If you���d like to peruse the outcome of this collaboration between Clearleft and Google, head on over to web.dev and learn responsive design. Then feel free to share it!

IntroductionMedia queriesInternationalizationMacro layoutsMicro layoutsTypographyResponsive imagesThe picture elementIconsThemingAccessibilityInteractionUser interface patternsMedia featuresScreen configurations

Media queries with display-mode

It���s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.

I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.

Best of all, I got to put my new-found knowledge to use! Here���s how���

The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.

In the web app manifest file for The Session, the display-mode property is set to ���standalone.��� That means it will launch without any browser chrome: no address bar and no back button. It���s up to me to provide the functionality that the browser usually takes care of.

So I added a back button in the navigation interface. It only appears on small screens.

Do you see the assumption I made?

I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?

Nope. If you���re using Chrome or Edge on a desktop device, you will be actively encourged to ���install��� The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.

So desktop users who install the progressive web app don���t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).

I was alerted to this issue on The Session:

It downloaded for me but there���s a bug, Jeremy - there doesn���t seem to be a way to go back.

Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:

.goback { display: none;}@media (display-mode: standalone) { .goback { display: inline; }}

Now the back button shows up if you ���install��� The Session, regardless of whether that���s on mobile or desktop.

Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?

If I hadn���t been writing about media features, I don���t think I would���ve been able to solve the problem. It���s a really good feeling when you���ve just learned something new, and then you immediately find exactly the right use case for it!

Today, the distant future

It���s a bit of a clich�� to talk about living in the future. It���s also a bit pointless. After all, any moment after the big bang is a future when viewed from any point in time before it.

Still, it���s kind of fun when a sci-fi date rolls around. Like in 2015 when we reached the time depicted in Back To The Future 2, or in 2019 when we reached the time of Blade Runner.

In 2022 we are living in the future of web standards. Again, technically, we���re always living in the future of any past discussion of web standards, but this year is significant ���in a very insignificant way.

It all goes back to 2008 and an interview with Hixie, editor of the HTML5 spec at the WHATWG at the time. In it, he mentioned the date 2022 as the milestone for having two completely interoperable implementations.

The far more important���and ambitious���date was 2012, when HTML5 was supposed to become a Candidate Recommendation, which is standards-speak for done���n���dusted.

But the mere mention of the year 2022 back in the year 2008 was too much for some people. Jeff Croft, for example, completely lost his shit (Jeff had a habit of posting angry rants and then denying that he was angry or ranty, but merely having a bit of fun).

The whole thing was a big misunderstanding and soon irrelevant: talk of 2022 was dropped from HTML5 discussions. But for a while there, it was fascinating to see web designers and developers contemplate a year that seemed ludicriously futuristic. Jeff wrote:

God knows where I���ll be in 13 years. Quite frankly, I���ll be pretty fucking disappointed in myself (and our entire industry) if I���m writing HTML in 13 years.

That always struck me as odd. If I thought like that, I���d wonder what the point would be in making anything on the web to begin with (bear in mind that both my own personal website and The Session are now entering their third decade of life).

I had a different reaction to Jeff, as I wrote in 2010:

Many web developers were disgusted that such a seemingly far-off date was even being mentioned. My reaction was the opposite. I began to pay attention to HTML5.

But Jeff was far from alone. Scott Gilbertson wrote an angry article on Webmonkey:

If you���re thinking that planning how the web will look and work 13 years from now is a little bit ridiculous, you���re not alone.

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

(I���m re-reading that article in the current version of Firefox: 95.0.2.)

Brian Veloso wrote on his site:

Two-thousand-twenty-two. That���s 14 years from now. Can any of us think that far? Wouldn���t our robot overlords, whether you welcome them or not, have taken over by then? Will the internet even matter then?

From the comments on Jeff���s post, there���s Corey Dutson:

2022: God knows what the Internet will look like at that point. Will we even have websites?

Dan Rubin, who has indeed successfully moved from web work to photography, wrote:

I certainly don���t intend to be doing ���web work��� by that time. I���m very curious to see where the web actually is in 14 years, though I can���t imagine that HTML5 will even get that far; it���ll all be obsolete before��2022.

Joshua Works made a prediction that���s worryingly close to reality:

I���ll be surprised if website-as-HTML is still the preferred method for moving around the tons of data we create, especially in the manner that could have been predicted in 2003 or even today. Hell, iPods will be over 20 years old by then and if everything���s not run as an iPhone App, then something went��wrong.

Someone with the moniker Grand Caveman wrote:

In 2022 I���ll be 34, and hopefully the internet will be obsolete by then.

Perhaps the most level-headed observation came from Jonny Axelsson:

The world in 2022 will be pretty much like the world in��2009.

The world in 2009 is pretty much like 1996 which was pretty much like the world in 1983 which was pretty much like the world in 1970. Some changes are fairly sudden, others are slow, some are dramatic, others subtle, but as a whole ���pretty much the same��� covers��it.

The Web in 2022 will not be dramatically different from the Web in 2009. It will be less hot and it will be less cool. The Web is a project, and as it succeeds it will fade out of our attention and into the background. We don���t care about things when they��work.

Now that���s a sensible perspective!

So who else is looking forward to seeing what the World Wide Web is like in 2036?

I must remember to write a blog post then and link back to this one. I have no intention of trying to predict the future, but I���m willing to bet that hyperlinks will still be around in 14 years.

Speaking of long bets���