Amazon Silk, Yet Another Web Browser

Amazon's long-awaited tablet/e-reader was formally announced today, and the conversations about whether or not it will compete the iPad are underway. I don't much care about that. I am far more interested in the web browser that it includes.

Amazon Silk is a new web browser, built on Webkit, and that is really the news of interest here. Add to that Amazon's super-proxy approach to help users get content more quickly and efficiently and you've now got a new pile of potential chaos as a web developer. It's far too early to tell how this will shake out, but in a client meeting today I already had to address it, so I think it warrants a little context for the current state of browsers so we can consider potential developer impact.

Amazon posted a video on its brand new blog to provide an overview of Silk (with an obligatory Geocities reference):

The 400+ comments raise some questions that tend toward a common theme — in the absence of a technical explanation, when can we get our hands on an emulator? Granted, there are plenty of comments about privacy, security, and some wild speculation, but the theme is clear.

As a web developer, I can tell you that we all feel overburdened with the assault of browsers we have out there already. We can champion the ideal of targeting the specs, not the browser, but when the clients call to complain about a rendering difference, not even a problem, on another browser it can get pretty draining. As Silk comes to market we'll need to account for it, its hardware configurations, and its coming release versions (within reason, of course).

For some context about the burden we already have, yesterday Google Chrome developer Paul Irish wrote that, only taking into consideration Internet Explorer for desktop, we're already on track to need to support 76 versions of just Internet Explorer (including version 8) through 2020. There are some broad assumptions in his article regarding how people will use the IE document modes, but the potential is still there. Add to that the new release schedule of many browsers (Firefox has gone from version 5 to 7 in ~90 days), and then pile on the browsers available for mobile devices, and we're already at well beyond the number of variations of browsers that we had to support even in the heyday of the browser wars.

But Silk isn't just a web browser — it's got a super-charged proxy server that will compress images, compile JavaScript into its own machine-readable format, and batch files into a singular, smaller download. While this is nothing new (Opera Mini has done this for some time on mobile devices), Amazon's implementation raises the hairs on the back of my neck when I think about all the years I've had to troubleshoot web applications because proxy servers are caching files, munging JavaScript, brutalizing images, and generally gutting the real-time features that the web had been moving toward more and more. I don't know if this will happen with Amazon Silk, but given my experience with Opera, proxy servers, and users in general, I am filled with apprehension.

Related

Opera responded to the Amazon Silk announcement with its own explanation of how its own "cloud-compression" technology works:

• Amazon’s Silk Web Browser Adds New Twist to Old Idea at ars technica.


• Amazon Launches Silk Web Browser for Tablets at Mashable.


• Amazon Silk browser spins a faster mobile web, courtesy of cloud servers (video) at Engadget.


• Opera: Amazon's Silk Browser is Flattering, But Five Years Late at PCMag.


• Amazon's Silk Browser May Not Be Smooth When It Comes to Privacy at PCWorld.


• Amazon's Silk browser one-ups Opera's approach to the Web at InfoWorld.


• The Implications of Amazon's Silk Web Browser at ReadWriteWeb

Read More

Web Accessibility Sorta-Infographic

WebAIM is a non-profit organization within the Center for Persons with Disabilities at Utah State University. It has a reputation (perhaps only in my head?) or providing resources both to the disabled and to organizations enlightened enough to want to support the disabled (or selfish enough to recognize they will be disabled as they age).

WebAIM makes the point that accessibility should be considered early in a web site's development, all the way back at the design phase (something lost on the Adobe Muse development team). WebAIM made a graphic, with accompanying text alternative, for its post Web Accessibility for Designers. It's not easy for me to be critical of an organization that does work for good (apparently not hard for me, either) but its latest infographic is nothing more than a pretty checklist (see the checklist below the graphic, but read the original post for more detail).

Web Accessibility for Designers

• Plan Heading Structure Early


• Consider Reading Order


• Provide Good Contrast


• Use True Text Whenever Possible


• Watch the Use of CAPS


• Use Adequate Font Size


• Remember Line Length


• Make Sure Links are Recognizable


• Design Link Focus Indicators


• Design a "Skip to Main Content" Link


• Ensure Link Text Makes Sense on Its Own


• Use Animation, Video, and Audio Carefully


• Don't Rely on Color Alone


• Design Accessible Form Controls

Read More

Social Media Spam Sorta-Infographic

Today's sorta-infographic contains four pie charts, one of which is supposed to show a range, and the other three are ostensibly based on 12 hour clocks. Despite it's clip-art-style graphics, it does provide some pretty interesting factoids and comes with accompanying text to explain the graphics and provide more details. You can read the commentary, and comments, at the original post: Debut Impermium Index Reveals Surprising Trends in Social Web Spam Attacks.

Some of the trends Impermium outlines:

• Online ID signup fraud.


• "Sleeper cells" of social web abuse are a ticking time-bomb.


• Social media exploitation techniques are evolving fast.


• Uggs was the #1 most exploited brand.


• Porn got stripped.


• Mom & Pop are spammers.

Much of this isn't news to many, but it is validating to those of us who wonder if what we are experiencing is in line with current trends. I suggest reading the comments to see some of Impermium's responses to criticism — ok, really just read the comments for the criticism.

Read More

Patent Wars Sorta-Infographic

I'm giving in to the cool hip trend of infographics that has been popping up like pinkeye across blogging and tech sites lately. These infographics are typically nothing more than data points (sometimes just narrative) strewn about with mathematically suspect charts or somewhat-related design elements. But they seem to draw traffic, even when there isn't even data to graph (Browsers as Wrestlers "Infographic"). So I am using my lack of shame to power through this long weekend with three posts of three infographics from other sites.

In today's installment I am posting an infographic that has some (imprecise) charts and a couple process maps outlining the current state of patents called Patent Wars: A New Age of Competition. You can find the original image at Business Insurance Quotes site, where it has no accompanying explanation or background.

Related

• Frivolous Patents on the Web


• WebM, H.264 Debate Still Going


• More Frivolous Patents


• A Patent Trolling Primer


• Are Patents Killing HTML5 Video?

Read More

We Really Still Have to Debunk Bad SEO?

I've been doing this web thing from the start (sort of — I did not have a NeXT machine and a guy named Tim in my living room) and I've watched how people have clamored to have their web sites discovered on the web. As the web grew and search engines emerged, people started trying new ways to get listed in these new automated directories, and so began the scourge of the Search Engine Optimization (SEO) peddler.

The web magazine .Net posted what to me is a surprising article this week (surprising in that I thought we all knew this stuff): The top 10 SEO myths. I am going to recap them here, although you should go to the article itself for more detail and the full list of reader comments. Remember, these are myths, which means they are not true.

1. Satisfaction, guaranteed;


2. A high Google PageRank = high ranking;


3. Endorsed by Google;


4. Meta tag keywords matter;


5. Cheat your way to the top;


6. Keywords? Cram 'em in;


7. Spending money on Google AdWords boosts your rankings;


8. Land here;


9. Set it and forget it;


10. Rankings aren't the only fruit.

The problem here is that for those of us who know better, this is a list that could easily be ten years old (with a couple obvious exceptions, like the reference to AdWords). For those who don't know better or who haven't had the experience, this might be new stuff. For our clients, this is almost always new stuff and SEO snake oil salesmen capitalize on that lack of knowledge to sell false promises and packs of lies. One of my colleagues recently had to pull one of our clients back from the brink and his ongoing frustration is evident in his own retelling:

I have a client who recently ended an SEO engagement with another firm because they wouldn’t explain how they executed their strategies. Their response to his inquiry was to ask for $6,000 / month, up from $2,000 / month for the same work in two new keywords.

This kind of thing happens all the time. I recently ran into another SEO "guru" selling his wares by promising to keep a site's meta tags up-to-date through a monthly payment plan. When I explained that Google doesn't use meta tags in ranking, his response was that I was wrong. When I pointed him to a two-year-old official Google video where a Google representative explains that meta tags are not used, his response was to state that he believed Google still uses them because he sees results from his work. My client was smart enough to end that engagement, but not all are.

Because I cannot protect my clients in person all the time, I have tried to write materials to educate them. For our content management system, QuantumCMS, I have posted tips for our clients, sometimes as a reaction to an SEO salesman sniffing around and sometimes to try to head that off. A couple examples:

• Verified: Google Ignores Meta Keywords


• SEO Spammers Using Your Contact Form

Along with these client-facing tips I sometimes get frustrated enough to write posts like this, trying to remind people that SEO is not some magical rocket surgery and that those who claim it is should be ignored. I've picked a couple you may read if you are so inclined:

• Verified: Google Ignores Meta Keywords


• Derek Powazek on SEO as Snake Oil

And because I still have to cite this meta tags video far far too often, I figured I'd just re-embed it here:

Related

My ire doesn't stop at SEO self-proclaimed-gurus. I also think social media self-proclaimed-gurus are just the latest incarnation of that evil. Some examples:

• Followers, Likes and +1s as Meaningless as Hits


• Social Scoring As the New SEO


• Lots of Twitter Followers Guarantees... Nothing

Read More

Followers, Likes and +1s as Meaningless as Hits

One of my un-fondest memories from my early days of web development was the constant client request for web site counters at the bottom of a new web site. Trying to explain to clients that showing a rather low number of visitors might not be something they want to brag about. And then I got the inevitable request to, like the sketchy used car dealer behind the warehouse, adjust the site counter ahead a few hundred thousand miles.

Today on the web services like Google Analytics, preceded by products like WebTrends, allow site owners to see the number of users visiting their sites without embarrassing themselves by displaying low numbers. These services have also allowed site owners to, for the most part, move past the goal of just getting hits on their sites and instead setting up better methods to track conversions — how many visits result in sales, or downloaded product, or filled out forms, or whatever the goal of the site is. Smart businesses aren't enticed by a count, they want to see numbers of qualified visitors.

So how do we not get this with social media?

I read an article earlier this week about a local firm doing good by helping local businesses to increase their Facebook "likes" (Buffalo Social Media Firm Focuses on Educating Local Clients). To be fair to the company being profiled, it's possible the writer just doesn't understand the business goals or what "educating clients" really means and did not provide sufficient context. When I see quotes like this I am more than a little surprised, given the boast of the article title:

"The key thing that a lot of people don't understand is it costs money if you want a 10,000 fan page. You've got to invest. You've got to run ads,” said Evanetski. Likes for the page have grown from around 450 before the ads launched to more than 1,700 by Sunday morning.

Nowhere does the article discuss just what those 1,700 fans actually mean for that business. Is the campaign over now, or are those fans being approached for more information, as sales opportunities, just for mining demographic data, or for something else? Educated clients should ultimately know that an increase in the number of people who follow / like / +1 them on a social media service in itself does not translate to anything. An educated client has a goal in mind and uses social media as one method to achieve that goal. If the goal is simply to garner fans and followers, then an opportunity is being missed.

I wrote about this very thing just a few days into 2010 — almost two years ago — and thought folks might catch on. It's worth a re-read: Lots of Twitter Followers Guarantees... Nothing. Seeing the reasons behind Newt Gingrich's absurdly high Twitter follower count (EXCLUSIVE: Twitter Analysis Vindicates Gingrich in Followers Scandal) should remind us all that such a high follower count is essentially meaningless, particularly if you've only cultivated followers who aren't prospects for your product or service.

If you are a business owner and are approached by firms offering to increase your Twitter follower count or Facebook likes (or other service-of-the-day verb-to-indicate-attention), just ask them, "Why?" The answer should include a tangible reference to your final goals for any marketing campaign. If it doesn't, then send them away.

Read More

Thoughts on Muse (Obvious Pun Avoided)

I downloaded and installed Adobe's new web design tool, Muse (code name) (also at Adobe Labs) out of morbid curiosity. Just like Adobe Edge (which refuses to launch), I had very little expectation that this would be a fully-developed sales-ready product. Instead of getting into extensive detail about the quality of its code, its accessibility support, and so on, I figured I'd do a very quick review of how I think it affects web developers.

The target audience is pretty clear from the Muse (code name) web site introduction:

Create websites as easily as you create layouts for print. You can design and publish original HTML pages to the latest web standards without writing code. Now in beta, Muse [(code name)] makes it a snap to produce unique, professional websites.

And this:

Design your pages

Focus on design rather than technology. Combine images and text with complete control, as flexibly and powerfully as you do in Adobe® InDesign®.

Right there is the gist of the product — enable print designers to convert their designs into web pages. Just like Photoshop would produce massive image slices to support Photoshop "designers," this product isn't about the code. With its integration of jQuery effects and Lightbox widgets, it seems almost like this would be a tool for a photographer to build a gallery site.

If you are a coder, or someone who cares about the code, this tool isn't for you. You will quickly see that the HTML is produces is not exactly structural or semantic, and that the piles of CSS and JavaScript aren't exactly necessary. Muse (code name) doesn't allow you to edit the HTML, so you still need to "publish" your work before you can edit it. If part of your coding process involves making your HTML meet accessibility standards or even just structure your content for good SEO, you will find it impossible.

If you are part of a web team, perhaps in an ad agency or interactive firm, then you will find that this tool doesn't allow you to collaborate well. If you get a favicon, for example, from another member of your team, Muse (code name) cannot import it; it only accepts PNG, GIF or JPG. If you receive a background image to drop into an element, Muse (code name) will crop the image, even increasing its dimensions to fill the element, regardless of your plan to allow more of the image to be revealed should the container change in size.

If you find yourself pasting HTML code from Google Maps or Twitter in order to embed third-party widgets on your site, you may find that is nigh impossible short of publishing your pages and then hacking through the HTML output. While I did not find a menu option to do that, even if it exists it will require a full "publish" step every time you want to tweak your embed code.

If you find yourself leaning on CSS techniques as simple as printable styles or as complex as media queries to support alternate display sizes, you will be disappointed. This tool is not intended to support liquid designs, adaptive layouts, document re-flow, or really anything related to alternate viewing.

If you support a web content management system, then for all the reasons above Muse (code name) is not a good fit. Just building a single page to use as a template will require a great deal of work to reformat the code to fit into most content management systems that are out there. Should you ever have to change the core template you either have to go back to Muse (code name) and repeat the process, or you will have to skip Muse (code name) for all future revisions.

In short, it comes down to these two key points:

1. Muse (code name) has the potential to be a great tool for the single graphic designer interested in showing off his or her work without having to learn a technology outside of his/her knowledge area (nor worry about accessibility, standards, alternate displays, SEO, etc.);


2. If you are a web developer (or web development firm), your job is not at risk. Muse (code name) is making no effort to replace you. If anything, it might keep you from getting fewer calls from people who might not be good clients anyway.

If you are looking for a pedantic review of the HTML output, I suspect plenty of others will cover that. Since Muse's (code name) target audience won't care, and anyone who does care will already know the issues just by playing around, it's not even worth getting into here. Besides, with 120,000 other people downloading Muse (code name) after the first day, I expect plenty of reviews of the markup will come.

Now to Examples!

These aren't intended to be open shots at Muse (code name), but instead I hope someone at Adobe can use them to help better it overall.

This image shows how Muse (code name) looks on my netbook (I may have tweeted my frustration last night). As you can see, the menus are off the top of the screen along with every other useful feature. I was able to close the application thanks to standard keyboard shortcuts.

Using the default page size settings (960 pixels with a min-height of 500 pixels), this is the sample site I quickly cobbled together. I did not start with a design or goal other than throwing some elements on the page, so don't tell me my site isn't as awesome looking as it could be. Because it couldn't be awesomer.

What about the file output you ask? Here is the /css directory:

File name	Size (bytes)
articles.css	5,106
bio.css	5,106
blog.css	5,106
books.css	5,106
contact.css	5,106
ie_articles.css	5,009
ie_bio.css	5,009
ie_blog.css	5,009
ie_books.css	5,009
ie_contact.css	5,009
ie_index.css	5,009
index.css	5,106
site_global.css	4,305

The duplicates are for IE support and you can expect to see all your content in every page twice as it relies on IE conditional comments to serve up one copy for IE9 and one copy for anything below IE9.

Here is the /scripts/0.9 directory:

File name	Size (bytes)
jquery-1.4.4.min.js	78,766
jquery.museMenu.js	2,382
MuseUtils.js	9,317
SpryDOMUtils.js	14,604

Without those script files, those simple-looking menus on my example just don't render.

That background image I mentioned earlier? Muse (code name) re-cropped it and converted it to a PNG file, increasing both the dimensions and file size:

File name	Size (bytes)	Dimensions
Banner_bg.jpg	11,271	627 x 80	original image
master_U355_full.png	41,800	960 x 97	Muse (code name) -ified image

Related

• Developers respond to Adobe Muse at .net Magazine.


• Adobe's Muse (code name) site re-coded as XHTML 1 strict, dropping from 78k to 5k.


• Added August 25, 2011: ZDNet asks, as a response to Muse (code name) criticism, What is wrong with bloated markup? I answer in the first comment.


• Added September 2, 2011: Even FastCompany weighs in on this: Adobe's Muse Lets Designers Make Websites Without Knowing Code

Read More