Tuesday 6 October 2015

OS X El Capitan and USB

I upgraded my MacBookPro to El Capitan two days ago and this was a huge mistake: suddenly, all my external USB hard disks, including my TimeMachine backup (based on a huge Seagate disk), stopped completely working. Not only El Capitan does not show the disks in the Finder, but the Disk Utility does not see them any more. In the release notes of OS 10.11 beta, one could read:

  • USB Known Issues
    • USB storage devices, including internal SD card readers, may become unavailable after system sleep and require either re-plug or restart to recover.
    • USB input devices may become non-functional on some Macs after several days.
    • USB 1.0, 1.1 and older 2.0 devices may not function.

I have tried to reboot, reset the PRAM, reset the SMC, nothing works. Online fora are full of people experiencing blocking issues with USB since they upgraded to El Capitan. The issue was reported by many people during the beta program of OS 10.11 and nothing changed.

This is lame and not at the Apple « level ». Hurry up Apple, fix this.

Thursday 24 September 2015

Calendar on iOS

Dear Apple, I have a request for enhancement for the Calendar app on iOS: when you add a new entry in a calendar, there a possibility to set a travel time. That travel time is hard-defined: 5, 15, 30, 60, 90 or 120 minutes. But since there is also the possibility to set an address for the entry, the travel time should be computed from the preferred transport method (car, foot, public transports) and my current location, looking at traffic data. With your Maps app, that's feasible and that would be a superb addition to the Calendar. Best.

Update: so apparently, this exists when you set up yourself an entry in the calendar. But I received a meeting invitation by email, with the address provided and everything ok, and Calendar lets me only set a hard-defined travel time...

Friday 11 September 2015

Death of XUL-based add-ons to Firefox

I will not discuss here right now the big image of the message sent a few weeks ago (although my company is deeply, very deeply worried about it) but I would like instead to dive into a major technical detail that seems to me left blatantly unresolved: the XUL tree element was introduced to handle very long lists of items with performance. Add-ons touching bookmarks, lists of URLs, list of email adresses, contacts, anti-spam lists, advertisement blocking lists and more all need a performant tree solution.

As far as I am concerned, there is nothing on the html side approaching the performance of the XUL tree for very long lists. Having no replacement for it before the removal of XUL-based add-ons is only a death signal sent to all the add-ons needing the XUL tree, and almost a "we don't care about you" signal sent to the authors of these add-ons. From an ecosystem's point of view, I find it purely suicidal.

So I have a question: what's the plan for the limited number of XUL elements that have no current replacement in html for deep technical reasons?

Update: yes, there are some OSS packages to deal with trees in html, but until the XUL tree is removed from Firefox's UI, how do we deal with it if access to the XUL element is not reachable from add-ons?

Thursday 30 July 2015

CSS Vendor Prefixes

I have read everything and its contrary about CSS vendor prefixes in the last 48 hours. Twitter, blogs, Facebook are full of messages or articles about what are or are supposed to be CSS vendor prefixes. These opinions are often given by people who were not members of the CSS Working Group when we decided to launch vendor prefixes. These opinions are too often partly or even entirely wrong so let me give you my own perspective (and history) about them. This article is with my CSS Co-chairman's hat off, I'm only an old CSS WG member in the following lines...

  • CSS Vendor Prefixes as we know them were proposed by Mike Wexler from Adobe in September 1998 to allow browser vendors to ship proprietary extensions to CSS.

    In order to allow vendors to add private properties using the CSS syntax and avoid collisions with future CSS versions, we need to define a convention for private properties. Here is my proposal (slightly different than was talked about at the meeting). Any vendors that defines a property that is not specified in this spec must put a prefix on it. That prefix must start with a '-', followed by a vendor specific abbreviation, and another '-'. All property names that DO NOT start with a '-' are RESERVED for using by the CSS working group.

  • One of the largest shippers of prefixed properties at that time was Microsoft that introduced literally dozens of such properties in Microsoft Office.
  • The CSS Working Group slowly evolved from that to « vendor prefixes indicate proprietary features OR experimental features under discussion in the CSS Working Group ». In the latter case, the vendor prefixes were supposed to be removed when the spec stabilized enough to allow it, i.e. reaching an official Call for Implementation.
  • Unfortunately, some prefixed « experimental features » were so immensely useful to CSS authors that they spread at fast pace on the Web, even if the CSS authors were instructed not to use them. CSS Gradients (a feature we originally rejected: « Gradients are an example. We don't want to have to do this in CSS. It's only a matter of time before someone wants three colors, or a radial gradient, etc. ») are the perfect example of that. At some point in the past, my own editor BlueGriffon had to output several different versions of CSS gradients to accomodate the various implementation states available in the wild (WebKit, I'm looking at you...).
  • Unfortunately, some of those prefixed properties took a lot, really a lot, of time to reach a stable state in a Standard and everyone started relying on prefixed properties in production web sites...
  • Unfortunately again, some vendors did not apply the rules they decided themselves: since the prefixed version of some properties was so widely used, they maintained them with their early implementation and syntax in parallel to a "more modern" implementation matching, or not, what was in the Working Draft at that time.
  • We ended up just a few years ago in a situation where prefixed proprerties were so widely used they started being harmful to the Web. The indredible growth of first WebKit and then Chrome triggered a massive adoption of prefixed properties by CSS authors, up to the point other vendors seriously considered implementing themselves the -webkit- prefix or at least simulating it.

Vendor prefixes were not a complete failure. They allowed the release to the masses of innovative products and the deep adoption of HTML and CSS in products that were not originally made for Web Standards (like Microsoft Office). They allowed to ship experimental features and gather priceless feedback from our users, CSS Authors. But they failed for two main reasons:

  1. The CSS Working Group - and the Group is really made only of its Members, the vendors - took faaaar too much time to standardize critical features that saw immediate massive adoption.
  2. Some vendors did not update nor "retire" experimental features when they had to do it, ditching themselves the rules they originally agreed on.

From that perspective, putting experimental features behind a flag that is by default "off" in browsers is a much better option. It's not perfect though. I'm still under the impression the standardization process becomes considerably harder when such a flag is "turned on" in a major browser before the spec becomes a Proposed Recommendation. A Standardization process is not a straight line, and even at the latest stages of standardization of a given specification, issues can arise and trigger more work and then a delay or even important technical changes. Even at PR stage, a spec can be formally objected or face an IPR issue delaying it. As CSS matures, we increasingly deal with more and more complex features and issues, and it's hard to predict when a feature will be ready for shipping. But we still need to gather feedback, we still need to "turn flags on" at some point to get real-life feedback from CSS Authors. Unfortunately, you can't easily remove things from the Web. Breaking millions of web sites to "retire" an experimental feature is still a difficult choice...

Flagged properties have another issue: they don't solve the problem of proprietary extensions to CSS that become mainstream. If a given vendor implements for its own usage a proprietary feature that is so important to them, internally, they have to "unflag" it, you can be sure some users will start using it if they can. The spread of such a feature remains a problem, because it changes the delicate balance of a World Wide Web that should be readable and usable from anywhere, with any platform, with any browser.

I think the solution is in the hands of browser vendors: they have to consider that experimental features are experimental whetever their spread in the wild. They don't have to care about the web sites they will break if they change, update or even ditch an experimental or proprietary feature. We have heard too many times the message « sorry, can't remove it, it spread too much ». It's a bad signal because it clearly tells CSS Authors experimental features are reliable because they will stay forever as they are. They also have to work faster and avoid letting an experimental feature alive for more than two years. That requires taking the following hard decisions:

  • if a feature does not stabilize in two years' time, that's probably because it's not ready or too hard to implement, or not strategic at that moment, or that the production of a Test Suite is a too large effort, or whatever. It has then to be dropped or postponed.
  • Tests are painful and time-consuming. But testing is one of the mandatory steps of our Standardization process. We should "postpone" specs that can't get a Test Suite to move along the REC track in a reasonable time. That implies removing the experimental feature from browsers, or at least turning the flag they live behind off again. It's a hard and painful decision, but it's a reasonable one given all I said above and the danger of letting an experimenal feature spread.

Monday 29 June 2015

CSS Working Group's future

Hello everyone.

Back in March 2008, I was extremely happy to announce my appointment as Co-chairman of the CSS Working Group. Seven years and a half later, it's time to move on. There are three main reasons to that change, that my co-chair Peter and I triggered ourselves with W3C Management's agreement:

  1. We never expected to stay in that role 7.5 years. Chris Lilley chaired the CSS Working Group 1712 days from January 1997 (IIRC) to 2001-oct-10 and that was at that time the longest continuous chairing in W3C's history. Bert Bos chaired it 2337 days from 2001-oct-11 to 2008-mar-05. Peter and I started co-chairing it on 2008-mar-06 and it will end at TPAC 2015. That's 2790 days so 7 years 7 months and 20 days! I'm not even sure those 2790 days hold a record, Steven Pemberton probably chaired longer. But it remains that our original mission to make the WG survive and flourish is accomplished, and we now need fresher blood. Stability is good, but smart evolution and innovation are better.
  2. Co-chairing a large, highly visible Working Group like the CSS Working Group is not a burden, far from it. But it's not a light task either. We start feeling the need for a break.
  3. There were good candidates for the role, unanimously respected in the Working Group.

So the time has come. The new co-chairs, Rossen Atanassov from Microsoft and Alan Stearns from Adobe, will take over during the Plenary Meeting of the W3C held in Sapporo, japan, at the end of October and that is A Good Thing™. You'll find below a copy of my message to W3C.

To all the people I've been in touch with while holding my co-chair's hat: thank you, sincerely and deeply. You, the community around CSS, made everything possible.

Yours truly.

Dear Tim, fellow ACs, fellow Chairs, W3C Staff, CSS WG Members,

After seven years and a half, it's time for me to pass the torch of the CSS Working Group's co-chairmanship. 7.5 years is a lot and fresh blood will bring fresh perspectives and new chairing habits. At a time the W3C revamps its activities and WGs, the CSS Working Group cannot stay entirely outside of that change even if its structure, scope and culture are retained. Peter and I decided it was time to move on and, with W3M's agreement, look for new co-chairs.

I am really happy to leave the Group in Alan's and Rossen's smart and talented hands, I'm sure they will be great co-chairs and I would like to congratulate and thank them for accepting to take over. I will of course help the new co-chairs on request for a smooth and easy transition, and I will stay in the CSS WG as a regular Member.

I'd like to deeply thank Tim for appointing me back in 2008, still one of the largest surprises of my career!

I also wish to warmly thank my good friends Chris Lilley, Bert Bos and Philippe Le Hégaret from W3C Staff for their crucial daily support during all these years. Thank you Ralph for the countless transition calls! I hope the CSS WG still holds the record for the shortest positive transition call!

And of course nothing would have been possible without all the members of the CSS Working Group, who tolerated me for so long and accepted the changes we implemented in 2008, and all our partners in the W3C (in particular the SVG WG) or even outside of it, so thank you all. The Membership of the CSS WG is a powerful engine and, as I often say, us co-chairs have only been a drop of lubricant allowing that engine to run a little bit better, smoother and without too much abrasion.

Last but not least, deep thanks to my co-chair and old friend Peter Linss for these great years; I accepted that co-chair's role to partner with Peter and enjoyed every minute of it. A long ride but such a good one!

I am confident the CSS Working Group is and will remain a strong and productive Group, with an important local culture. The CSS Working Group has both style and class (pun intended), and it has been an honour to co-chair it.

Thank you.


Wednesday 3 June 2015

In praise of Rick Boykin and its Bulldozer editor

Twenty years ago this year, Rick Boykin started a side project while working at NASA. That project, presented a few months later as a poster session at the 4th International Web Conference in Boston (look in section II. Infrastructure), was Bulldozer, one of the first Wysiwyg editors natively made for the Web. I still remember his Poster session at the conference as the most surprising and amazing short demo of the conference. His work on Bulldozer was a masterpiece and I sincerely regretted he stopped working on it, or so it seemed, when he left NASA the next year.

I thanked you twenty years ago, Rick, and let me thank you again today. Happy 20th birthday, Bulldozer. You paved the way and I remember you.

Tuesday 21 April 2015

Samsung Gear Fit, or « hardware obsoleted by software »

Samsung Gear FitFollowing a hint given by someone a few days ago during the Bulgarian Web Summit, I was quite shocked to discover this morning that my Samsung Gear Fit is obsolete, software-wise. The Gear Fit was released with the Samsung S5 a year ago, on the 11th of April 2014. Although a bit limited and even buggy, it's a pretty interesting device partly because of its very peculiar form factor. It was said to work only with a few Samsung devices, but many people succeeded using it with all sorts of Android devices. I wish I could use it with my iPhone but that's unfortunately not an option.

The Gear Fit has a few downloadable extensions, based on a SDK also released a year ago. The fact extra apps can be created and maintained is a very important indicator of not only the market success of a given device, but also of the obsolescence of the device.

That SDK is not available any more from http://developer.samsung.com, as it is confirmed here. And it's not a very recent change. Samsung then turned obsolete - because of software - a hardware they released less than a year ago. From a customer's perspective (again, I bought that device), that's pretty shocking.

The Samsung Gear Fit is still available everywhere here in France, from Orange stores to supermarkets. But it's a dead duck without a SDK. Don't buy it.

Monday 9 March 2015

e-junkie's mega FAIL on EU VAT

I have been using e-junkie for my sales of BlueGriffon add-ons and BlueGriffon EPUB Edition for years. Quite happily until recently. But this changed and I am now extremely upset by the way e-junkie dealt with the recent changes in VAT in the European Union.

Until the 31st of december 2014, using them to sell a downloadable product world-wide from a business inside the EU was easy. You only had to set your price without VAT and check a checkbox to apply VAT to your sales to european customers. One single price, one single sales button and shopping basket, e-junkie handled your VAT rate based on your business's country.

Since the 1st of january 2015, the EU rules have changed. A bit painful but certainly not unbearable: the VAT rate to apply to european customers is not based on the business's location any more but based now on the customer's location.

In short, it means that in 2014 e-junkie was determining the VAT rate to apply from an array of 27 values looking for the business's country. In 2015, the value should be retrieved from the customer's value, something that is perfectly doable for e-junkie since it can, at the shopping basket level, require the user to enter his/her country of residence and even the zipcode.

But no, e-junkie declined to do so and completely changed its behaviour overnight. Starting 01-jan-2015, the unique price you set in e-junkie for a product INCLUDES VAT for european customers...

E-junkie leaves a few ugly options to european businesses: have one sales button for EU customers and one for others (urgghhh...), offer a discount code to non-EU customers and other ugly solutions of that kind. E-junkie say they must validate the address and that can be done only after the bank/paypal has accepted the sale or something like that. That argument is not acceptable, since all european users of e-junkie perfectly know some european users cheat and give for instance a US address for downloadable purchases, to avoid paying VAT. It cannot be worse. And the argument that e-junkie had to do this or that does not stand, e-junkie is not a european company and does not have to comply with European Directives, they're outside of the European jurisdiction.

E-junkie has left all its european customers in limbos with respect to EU VAT. It really looks like they did not want to touch their code and UI - that have not changed in years. They already had the array of 27 VAT rates in the EU, and the VAT was  added only after the shopping basket had verified both the customer and the business were in the EU. Their refusal to tweak their code - and as a programmer I cannot believe the change was complex - is a true shame.

Let me state it clearly: this is a failure of a rarely seen magnitude and I am now looking for an alternative to e-junkie dealing better - dealing at all should I say - with EU VAT rates. I have recommended e-junkie to a gazillion of EU businesses. I am now recommending them to flee and find another shopping basket manager.

If you have a suggestion for an alternative to e-junkie, please leave a comment? Thanks!

Monday 2 March 2015

Vivaldi, the browser

Vivaldi is the new kid on the block. It's not a new rendering engine, since it relies on Google's Blink, but it's definitely a new browser.

But I have a gut feeling this is not only a company and a browser. It's also a personal revenge on Opera's current board and the company was formed as such. Jon von Tetzchner has enough capital to do that w/o caring too much about the money, and the words of Tatsuki Tomita, co-founder, « we feel that there is a need for a more powerful browser for people who want more from their browser » are a bit lightweight as a business plan for a free app, really.

Even if it's based on Blink and not on Presto any more, Vivaldi aims at continuing where Opera stopped. The first feedback from users is very clear on that. And no need to comment more on the Opera and Vivaldi names, right?

We'll see where it goes from here, and if Vivaldi's Jon does not become in the future for Opera what NeXT's Steve Jobs became for Apple, something I am 100% sure he has in mind :-)

Lykke til, Jon !

Adobe Edge Reflow anyone?

Edge ReflowI received this morning a message from the Adobe Edge Reflow prerelease forum that triggered my interest. I must admit I did not really follow what happened there during the last twelve months for many various reasons... But this morning, it was different. In short, the author had questions about the fate of Edge Reflow, in particular because of the deep silence of that forum...

Adobe announced Edge Reflow in Q3 2012 I think. It followed the announcement of Edge Code a while ago. Reflow was aimed at visual responsive design in a new, cool, interactive desktop application with mobile and photoshop links. The first public preview was announced in February 2013 and a small community of testers and contributors gathered around the Adobe prerelease fora. Between January 2013 and now, roughly 1300 messages were sent there.

Reflow is a html5/JS app turned into a desktop application through the magic of CEF. It has a very cool and powerful UI, superior management of simple Media Queries, excellent management of colors, backgrounds, layers, magnetic grids and more. All in all, a very promising application for Web Authoring.

But the last available build of Reflow, again through the prerelease web site, is only a 0.57.17154 and it is now 8 months old. After 2 years and a half, Reflow is still not here and there are reasons to worry.

First, the team (the About dialog lists more than 20 names...) seems to have vanished and almost nothing new has been contributed/posted to Reflow in the last six to eight months.

Second, the application still suffers from things I identified as rather severe issues early on: the whole box model of the application is based on CSS floats and is then not in line with what modern web designers are looking for. Eh, it's not even using absolute positioning... It also means it's going to be rather complicated to adapt it to grids and flexbox, not even mentioning Regions...

Reflow also made the choice to generate Web pages instead of editing Web pages... It means projects are saved in a proprietary format and only exported to html and CSS. It's impossible to take an existing Web page and open it in Reflow to edit it. In a world of Web Design that sees authors use heterogeneous environments, I considered that as a fatal mistake. I know - trust me, I perfectly know - that making html the pivot format of Reflow would have implied some major love and a lot, really a lot of work. But not doing it meant that Edge Reflow had to be at the very beginning of the editorial chain, and that seemed to me an unbearable market restriction.

Then there was the backwards compatibility issue. Simply put, how does one migrate Dreamweaver templates to Reflow? Short answer, you can't...

I suspect Edge Reflow is now at least on hold, more probably stopped. More than 2 years and still no 1.0 on such an application that should have seen a 1.0beta after six to eight months is not a good sign anyway. After Edge Code that became Brackets in november 2014, that raises a lot of question on the Edge concept and product line. Edge Animate seems to be still maintained at Adobe (there's our old Netscape friend Kin Blas in the list of credits) but I would not be surprised if the name is changed in the future.

Too bad. I was, in the beginning, really excited by Edge Reflow. I suspect we won't hear about it again.

Monday 23 February 2015

Manly Beach

Soooo... When I was in Sydney, I had to find a doctor and then a pharmacy to buy a strong antiseptic cream. Beach's sand (more probably sharp bits of shell) created four scratches between two toes of my right foot and after a day and a half, it became slowly red, and it started swelling and oozing. And the smell was not normal. It was also quite painful. It was of course an infection, that the cream fortunately helped curing in less than two days. But now it happens I have a second extremely similar skin infection elsewhere, also happening on sand scratches, and that started very slowly after my last half-day in Sydney, half-day I spent on the same beach while my CSS WG friends were scuba-diving 300m away.

I have never walked barefoot outside of the beach, I had socks inside my light shoes so the only place I could get it from was the beach.

I am therefore seriously questioning the cleanliness of the sand at Manly Beach or worse, the pollution of the water. I read that bacterial water pollution can be rather high in Manly after rainfalls or storms and I wonder if the sand on the main beach is not accumulating that bacterial pollution... In Europe, such spots are regularly disinfected and I wonder if it's the case on Manly beach. All in all, getting not one but two skin infections from sand scratches at the same beach, on two different moments, does not seem to me a coincidence... FWIW, I never had such skin infections before.

Sunday 8 February 2015

CSS Parser and Tokenizer API

The first time I mentioned the need to reach the internal CSS parser of a rendering engine from JavaScript was 17 years ago during the CSS WG meeting I hosted at Électricité de France in 1998, during a corridor discussion. All the people around said it was out of question. Then I put it back on the table in 2002, with little success again. Today, I was actioned by the CSS WG and the TAG in the Houdini Task Force to start editing a new document (with Tab Atkins, Shane Stevens and Brian Kardell) called CSS Parser and Tokenizer API. It does not say it's going to be accepted or anything, but at least it went beyond the 5 minutes chat and rebuttal. I am extremely happy and proud :-) If we succeed making it happen, this is going to be a game-changer for a lot of web applications!!!

Wednesday 4 February 2015

In praise of Tristan Nitot

There's a high probability Tristan and I met when we were kids. We were both hanging around the same places at the same time to have access to computers. We met again during the early years of Netscape, while I was leading everything web-related at Électricité de France. Later, he was of course the first one to greet Peter and I when we joined as sherpas in november 2000.

On the 15th of july 2003, Tristan, Peter and myself were on the "special" conference call about a "reorganization". In the next minutes, all our colleagues from the US sent a farewell message and Netscape was no more. After the summer break, Tristan, Peter and myself met at Peter's apartment in Paris to discuss our future. I suggested to take advantage of the OSS nature of Mozilla and launch a software company, but Tristan and Peter had only one idea in mind and it was already called "Mozilla Europe"... I eventually launched "Disruptive Innovations" alone while they remained focus on their project.

Tristan and Peter worked incredibly hard to achieve that, giving Mozilla a unique and powerful presence on the Old Continent. After the official launch of Mozilla Europe, Tristan became ubiquitous. He was so present in European media I started the Tristant-Nitot-Tracker as a joke. Newspapers, Web magazines, radios, television channels, there has not been a single day between 2003 and 2011 without multiple appearances of Tristan everywhere in Europe, and sometimes beyond. I never understood how Tristan found the time and energy to make Mozilla so visible in the media here.

The face of Mozilla Europe is - we'll soon have to say was - Tristan. There's that classic and completely stupid french proverb that says "nobody is irreplaceable"... If someone you hired is replaceable, it only means you have to improve your hiring process. Successes are built with irreplaceable people.

Tristan is irreplaceable, because he's not only giving work, skills, energy and talent. He's doing it in a way that is from my perspective unique: tons of humor in absolutely all circumstances, extreme dedication, convinced and convincing spirit, ability to discuss with absolutely anyone from geeks to politicians, outstanding spoken and written communication, indisputable loyalty, inspiring everyone.

I'm not a Mozilla employee. But Tristan has been, as Mozilla Europe's leader, a crucial person to my company. So let me thank him deeply and sincerely for all the fish he gave me, all the fish he gave us all.

Tristan, all I can say is that you now have more free time to ride your motorbike to come have lunch with me in Saint-Germain! Best of luck for the future, the coaching and the book!

Monday 26 January 2015

En vrac

  • Customers' response to the launch of Samsung Tizen Z1 in India is said to be « freezing cold » and a « failure ». I'm clearly not surprised.
  • -1 again on Samsung Open Source Group's headcount, what a success. Not sure Samsung has even one person in the whole world still working full-time on Servo...
  • but in the meantime, Samsung launched a great DSLR with Tizen inside.
  • IBM announced the Layogeddon. 111,800 persons let go before the end of the month.
  • my Quaxe project received an « E-Toiles d'Or 2015 » award

Wednesday 14 January 2015

Reflections on the Samsung Z1 launch

The difficult steps of Samsung in the software world

Important disclaimer: I worked for Samsung Research America as a full-time contractor from september 2013 to june 2014, and have been maintaining there no contacts but personal ones since then. The following lines represent only my personal opinions and do not contain any detail or information that were not published by the Press before if you except what people having no employment or contractual link with Samsung shared with me between september 2014 and today.

A Tizen-based phone, finally..

After a long, long, really long wait, Samsung finally releases one Tizen-based smartphone to the market. The Z1 is now available in India for a unsubsidized price of 5,700 rupees, so roughly 78€. The full specs of the beast are available for instance here. Here are my thoughts about that release...

First, the name of that smartphone is badly chosen. Very badly even. The successful Sony Xperia Z1 was released Q3 and Q4 2013 and googling Z1 usually drives to the Sony smartphone almost everywhere in the world. Of course, because of the release, references to the Samsung release are now on top of list but that won't last if the Samsung Z1's market does not rapidly increase. As a matter of fact, some of the first Indian articles about the Z1 are not that impressed.

The smartphone is almost similar to the ZTE Open C that runs Firefox OS if you except the fact the Z1 is dual-SIM. Even the price is the same. But the ZTE is available in many countries and received extremely positive reviews even here in France. Firefox OS is also available on a high-end device in Japan, crossing a segment boundary that Samsung does not seem ready to cross with Tizen.

It can run Android apps, through OpenMobile ACL (Applications Compatibility Layer) available in the new Tizen Store (no URL, reachable only from a Tizen device...). This is important and there are many positive and negative things to say about it. First, it shows that despite of injecting literally millions of dollars into software companies, Tizen has not attracted a big enough Apps catalog to live standalone. I even heard last month from a software company that ported its app to Tizen that they don't care about Tizen at all, they just caught Samsung's money and don't plan to update their Tizen app after that.

OpenMobile ACL is not an emulator. Apps should almost run at native Android speed. So that is quite positive from an end-user's perspective if you except one tiny detail: reaching and running Android Apps now rely on third-party software that is another problematic layer in the bigger Android fragmentation issue. OpenMobile ACL say on their web site they provide an AppMall for Android apps. I have no confirmation about this but my first thought is that it is necessary to make sure OpenMobile ACL users only download and try to run apps that are validated, i.e. apps that are known to work under ACL. AppMall is probably integrated into the Tizen Store. So what about the version of Android ACL allows? And what about ACL's updates? No word.

One word about ACL: a "Samsung spokesperson" denied Tizen on the Z1 can run an Android app without having the code re-written. Given what OpenMobile says on their own web site about ACL, I would be more than cautious about the authoritativeness of that clarification...

All in all, OpenMobile ACL's presence in the Tizen Store and the fact it's officially shown as a sales argument is not a good signal for Tizen itself. Will developers have any incentive to develop natively for Tizen? I don't think so. Will ACL's limited openness to the Android world be a problem? Almost certainly. Furthermore, the whole Tizen story was about building an alternative to Android and the Android app ecosystem; that strategy seems to have failed at least in Samsung execs' minds, and Tizen is, at least for the time being, unable to provide Samsung Electronics with such an alternative. I fail to see how that situation could improve in the near-term future without drastic strategic changes.

The Z1 is fueled by Tizen 2.3, released in December 2014, after a loooooong history you can read summarized here. And after so much time and many, many hesitations at Samsung that CNet reported about (launch announced, launch delayed, launch area restricted, launch suspended, again and again), it's amazing to watch the pace of Firefox OS, that went from inception in July 2011 to market availability in nearly 30 countries in December 2014 on phones, TVs, tablets, watches and even a TV stick. Firefox OS also has attracted many app developers, without subsidizing them, because it's a true open HTML5-based platform.

The browser inside the beast is clearly Blink-based, so that's another extremely strong tie to Google. A while ago, Samsung announced a collaboration with Mozilla to work on a new rendering engine, Mozilla Servo. Seen from github, that collaboration seems to have drastically fallen.

That said, let me tell you what I think of Tizen at Samsung.

What's wrong with Samsung's software

Samsung is a hardware leader. This is clear, recognized by all and quite stable. Yeah, well, its smartphone market share may suffer a bit these days but its chips and parts are still everywhere.

But it's nowhere in software (yeah, yeah, I know Samsung is a huge contributor to Linux) because the company and its processes seem mostly unadapted to software. The software stack of my connected Samsung TV sucks, the software bundled with my Samsung laptop all suck so deeply I deleted them, Kies for mobile devices (think iTunes) that is major visibility thing for Samsung is a endless subject of laugh and unfortunately cries for everyone I know, my Samsung S5 was so plagued by ugly UI, system bugs, painfully annoying and totally useless additions to Android that I finally moved back to Apple.. And Tizen is... well... stop the first person around the corner and ask "have you ever heard of Android? iOS? Windows? Tizen?". There are remarkable bits inside Tizen; Linux, EFL and more. It's the whole packaged thing that feels wrong.

To maintain a hardware leadership on devices, Samsung absolutely needs to become a software leader.  That won't be easy. First it needs to adapt to the software engineering culture and that implies opening a full Pandora's box because software engineering culture remains mostly a fact of the western world. To master software, Samsung then needs to move one of its centers of gravity outside of Korea, a true taboo as of today. This not hyper-specific to Samsung; most Korean companies suffer from the same issue and are unable to become global. It also means Samsung must induce a self-revolution to attract software engineers because the projects are exciting and will change the world, and not only because of the salaries, reported as being pretty high on Glassdoor. Samsung is known to be a rather vertical company, and that certainly fits well with hardware processes. It does not fit at all with software ones. All of that will require the implementation of drastic changes in the company. Again, Samsung is far from alone in that situation. Openness of mind is not a message, it's a core feature.

In that perspective, Android is at the same time an enabler and a blocker. Enabler because it clearly helped Samsung reach the #1 position on the mobile phone market but blocker because Android and its Play Store are in the hands of a partner that is also a competitor. Big names own an operating system and a browser stack. You can name four, in alphabetical order, and that's all: Apple, Google, Microsoft, Mozilla. Period. The others can reach a #1 position in sales but they will always remain strategically behind these ones because they don't own the full thing.

But Tizen seems to be managed by Samsung, at the highest level and not the technical one, by people who haven't understood at all how to insert it into the market. Or maybe they have and they were blocked by the corporate structure, which is clearly worse.

  1. you can't flash your personal phone, even a Samsung one, with Tizen. Holy cow, read that again: Tizen is heading towards version THREE ZERO and you still can't try it on any personal phone, even a Samsung one.
  2. so-called "reference phones" are so old/weak they cannot trigger developers' or manufacturers' interest. They're also rare and difficult to obtain.
  3. who cares about a Tizen emulator on a desktop computer when there are no phones in the wild...

So Samsung urgently needs to change that. It needs an extra team with one single goal: provide as soon as possible Samsung phone owners all around the world with flashable builds of Tizen for the longest possible device list (and of course easy way back to Android). That's where politics could enter the game, with the tenants of the Google partnership probably refusing collaboration on that ground. This is pure speculation of mine but I would not be surprised if it was later confirmed. The conclusion is simple: if Tizen is thought to be an answer to the decorrelation-from-Google question, then the decision to support and release has to come from the highest level in the company and be very strictly enforced. And if not, Tizen has to be ditched. In my opinion, Samsung must have its own OS stack to be a top player instead of being only a major player. It has to shift a large part of its growth from hardware to software and user experience.

Tizen itself needs, at the technical level, some major love. Its Web API is so different from the stable or proposed W3C API it's utterly shocking. Even the Alarm API, authored on both sides by a former Intel employee who spent a rather short while at Samsung and eventually left to Apple (ahem...), shows incompatible specs. The whole SDK needs a complete review, and revamp. Open Web Standards must be the only ground layer there.

At the UI level, Tizen is almost a clone of an old version of Android, and there is no fun using it. Tizen UI has nothing special, nothing exciting or different. Seen from a meter away, one is unable to say if a given phone is running Android or Tizen. So Samsung needs UI designers totally free to push the limits far beyond what Samsung is usually able to do in terms of UI. You may or may not like the tiles of Windows Phone, but they're a distinctive sign of Microsoft and the slowly but steadily increasing market share of Microsoft seems to indicate many people actually like them. Tizen has nothing like that for the time being.

The app layer is again a tough choice: native or web-based? C++/Java or HTML5? Still or sparkling? It's 2015 and developers should still love to code in, ahem, Java? Seriously? The largest pool of developers in the world is on the Web, every single web page author can be turned into a Web-based app author at very little cost, and the Tizen Z1 will try to gain success using a compatibility layer with Java-based apps? Wow. The future of apps is clearly HTML5-based even if some native apps will remain.

And then comes the browser issue... As I said above, a major corporation that does not own a browser stack is a major player, not a top one. And using Blink inside Tizen preserves a tie to Google that is completely counter-strategic and certainly harms the whole original Tizen plan. Samsung, like all other major smartphone manufacturers, needs a 64-bits multi-threaded rendering engine with parallel layout, to extract the highest performance - and the lowest battery drain - from multicore CPUs. It also needs its own rendering engine because the rendering engine is a core element of most Apps so innovating in that engine is a key factor of market success. Innovation should not be in the hands of a third-party, even a long-time partner and a fortiori not a competitor.

What Samsung needs to do to fix its software effort

My advices to Samsung about Tizen would be the following ones, even if I could say the same to any of their major Android-based competitors:

  1. yes, you need your own OS. It would be a very serious strategic mistake to ditch or even limit Tizen.
  2. no, OpenMobile ACL is not a killer feature, don't forget the downsides and the fact others OSes like Firefox OS can have it too.
  3. no, its current UI and UX are clearly not enough and you need a deep investment there.
  4. no, the way you try to increase Tizen's visibility and external contributions to the Tizen ecosystem does not feel right. Look at how Ubuntu Mobile or Firefox OS built a community and do the same.
  5. no, sorry, Tizen is far behind competitors in terms of modernity and openness. You must implement drastic changes there, and that goes down to the technical layer.
  6. yes, to do that, you must implement globalization. You must implement it anyway for a zillion good reasons. That will require cultural changes and a less vertical organization.
  7. yes, to do that, you also must release Tizen to existing devices, and you must even release nightly builds. Make "early adopters" become your best evangelists.
  8. no, you're not good enough, not open enough and not disruptive enough in the software world. To do something different, you must do it differently and with different people and habits. Accept it and apply it. The more you wait, the harder it will be.
  9. no, you just cannot wed yourselves eternally with Blink. You need your own rendering engine to fully unleash the hardware power of your devices and stimulate the rest of your software innovation. This remark is also valid for the browser on Android, although I'm not sure the new terms of the Android embedding agreement still allow the bundling of an extra browser...
  10. in that light, the Samsung Tizen Z1 could, perhaps, address the low-end segment of the market in some geographic areas but it's hardly the announcement of a new and successful OS ecosystem.

Update: mention of Android 2.3 for ACL in Z1 deleted after new input.

Friday 9 January 2015

No comment

HTTP headers
Screenshot by Robin Berjon following a message of mine

Sunday 21 December 2014


Welcoming Bloomberg as a new customer of Disruptive Innovations. Just implemented the proposed caret-color property for them in Gecko.

Saturday 20 December 2014

Sims4 WTF

My son Gabriel got as a present the Sims4 game for Windows. He tried to install it on his Win7 Ultimate 64bits box but no luck at all, Origin crashing in msvcr100.dll with a c0000417 error. Despite of looking everywhere for an hour, we could not find a fix. Since I'm sure some of my readers have already hit - and solved - this issue, can you please help? Thanks a lot !

Thursday 18 December 2014

Bulgaria Web Summit

I will be speaking at the Bulgaria Web Summit 2015 in Sofia, Bulgaria, 18th of april.

Wednesday 26 November 2014

Yosemite maximize/fullscreen button

The always remarkable Wladimir Palant has found a fix for the most annoying OS X "feature" ever, the change of behaviour of the window maximize button. In Yosemite, it now defaults to fullscreen and you have to press the Alt key to get the "classic" behaviour of window maximization. This is so painful all the people I know are currently asking how to reverse that. Given the very negative feedback, I'm pretty sure Apple will at some point in the future introduce a defaults allowing to reverse that from the command line, but for the time being we're all cursing in front of our Mac when we toggle an app fullscreen instead of maximizing it. Apple, read it well: One Does Not Change a 25 Years Old Behaviour; remember the Windows Start button. Oh, and the fullscreen standalone button on the right hand side of the titlebar was better than the current Yosemite blurby hack.

Soooo... Wladimir found that free piece of software called BetterTouchTool (BTT). Follow the steps below:

  1. Download BTT and install it.
  2. During installation, your mac may ask you to allow Preferences to control accessibility, that's normal
  3. In the main BTT window, click on the Other button in the main toolbar

    (image 1)

  4. Create a new trigger and select the "Leftclick Green Window Button"

    (image 2)

  5. Click on the Predefined Action dropdown button and type "zoom" in the search field

    (image 3)

    select "Zoom window below cursor"
  6. Create a new trigger again and select again "Leftclick Green Window Button" (see step 4 for the image)
  7. Check the "Opt" button

    (image 4)

  8. Click on the Predefined Action dropdown button and type "full" in the search field

    (image 5)

    select "Enter fullscreen"
  9. You can now close the window ; make sure BTT is running at all times.

Thanks Wladimir and thanks BTT! Not perfect but better than regular Yosemite's behaviour!

- page 1 of 120