![\"Rotation](\"/images/posts/2022-03-15-lock.jpg\" "\\"Rotation")
I'm French and I don't have a lot of experience translating an app in Chinese or Arabic, for example, so take the following tips with a grain of salt in this kind of context. Feel free to contact me if necessary!
Displaying a date is extremely common in digital products, but using a clear format requires a few more considerations.
\nHere are just a few examples of what is possible:
\nDD-MM-YYYY → \"06-04-2022\"
DD/MM/YYYY)MM-DD-YYYY → \"04-06-2022\"
YYYY-MM-DD → \"2022-04-06\"
DD Month YYYY → \"06 April 2022\"
DD Mon YYYY → \"06 Apr 2022\"
Almost any programming language has a powerful API to format a date however its developer wants.
\nThus, it's easy to use a dozen different formats in a single app if you don't set strict standards and conventions. Moreover, some formats work for some countries but not in others.
\nTo simplify and clarify things, I highly recommend to only use two formats in the applications I work on.
\nFor technical, compact and/or dense data, I use the ISO 8601 version: YYYY-MM-DD → \"2022-04-06\".
Why?
\nThere is only one way to read it: the year first, then the month and finally the day
\nDD-MM-YYYY or MM-DD-YYYY, you cannot tell if the month or the day is first, except by looking at the current language of the app (and you can still be wrong if you cannot distinguish if it's British or American English)- symbol works everywhere, while / can be refused by some (old) filesystemsNote: I always advise to prefix single-digit months and days by 0 so the format keeps an equivalent visual weight and is easier to parse: 2022-01-01 instead of 2022-1-1
For dates supposed to be quickly read by humans (in an article or a blog for example), I prefer to use DD Month YYYY → \"06 April 2022\" (with the full name of the month and not a shorter form).
Why?
\nFinally, if you only want to display a month (in a dropdown for example), I recommend to always show both the month number AND the month name: 01 - January instead of January or 01.
That way, you can visually search for or type the month name or number, and match any input you have at hand (eg. a credit card's expiration date).
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2023-06-09T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2023/02/social-start/", "url": "https://matthieuoger.com/2023/02/social-start/", "title": "On Instagram's Start", "content_html": "\n\n\n[…] I want to point out that when we launched Instagram, it was a filter app first for everyone. Most people didn’t even know that there was a network behind it. It was a filter app. My intention was always for it to be a social app, and I was bummed when everyone talked about it as a filter app.
\nBut what I realized in there is that the best networks are first to utility, and then they piggyback on that utility, and they become a network. I think Facebook’s actually a great example of this. It may not be so clear, but it was clearly just a directory at the beginning. It was about finding people, communicating with them. And then it became the social network that it became once they added the news feed and all this other stuff.
\nSo Instagram and Facebook are actually not that different in their evolution. [We decided] when we talked about launch, that we were just going to focus on the utility part of it first and be really good at that because starting a social network from scratch, I think, is the wrong order.
\nYou see a lot of people launching things today that are social networks first and then utility is questionable. And it’s because the utility in the social network only makes sense when you’re at scale, when you have a lot of people. And it’s very hard to bootstrap that.
\n
(Emphasis mine)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2023-02-17T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2023/02/alpha-value-css-color-properties/", "url": "https://matthieuoger.com/2023/02/alpha-value-css-color-properties/", "title": "Alpha Value in CSS Color Properties", "content_html": "Today1, I learned that that you could use a / alpha value in CSS color property functions (hsl, rgb, etc.).2
It looks like this:
\ncolor: hsl(0 0% 0% / 0.5);\ncolor: rgb(0 0 0 / 0.5);Where the alpha value is a number between 0 (full opacity) and 1 (no opacity).
Previously, you had to use a function variant to change the alpha:3
\ncolor: hsla(0, 0%, 0%, 0.5);\ncolor: rgba(0, 0, 0, 0.5);(Note the a at the end of each function, ie. rgb → rgba.)
This is really handy, because you can change the content of the function without changing the function name itself. Which is more practical when using React and CSS-in-JS libraries. I know I would have use that a few times already if I was aware of this small spec change.
\nThe support is pretty good (more than 92%), so it's mostly safe to use on modern websites.
\nIt's not really new anymore, but I don't code that much nowadays. That was a small nice surprise. ;)
\n↩\nI (and others) still recommend to use the hsl function instead of rgb or hex values. It's more powerful and as soon as you grasp how the model works, it's easier and quicker to manipulate. Especially for variables and theming purposes.
The old notation still works, but it's considered legacy.
\nThe commas are also optional now (and considered legacy as well).
\n AND there is another syntax using commas and an alpha value (hsl(0, 0%, 0%, 0.5) / hsla(0, 0%, 0%, 0.5)) or an alpha percentage (hsl(0, 0%, 0%, 50%) / hsla(0, 0%, 0%, 50%)).
Basically, you can do anything you want, but using the / alpha syntax without commas and a suffix in the function name is the proper and preferred way. 🥴
Gabriel Weatherhead in “Playbooks Before Automation”:
\n\n\nI’m not a professional engineer but this is something I naturally do for anything that takes more than a half dozen steps. […] While I was toiling away in [Excel] I wrote down what I was doing in a note.
\nBy the time I was done I had repeatable instructions for myself. Clear steps make automation easier and a lot more fun.
\n
(Emphasis mine)
\nI think Playbook is a really good word to describe this habit.
\nI tended to use \"Checklist\" instead, but I do think Playbook encapsulates this concept way better. You are not writing tasks to perform mindlessly, but you are also giving context1, warnings and the story.2
\nGabriel is also quoting another excellent article, by Jacob Kaplan-Moss:
\n\n\nWrite playbooks before automation […]
\nWe know that writing some code to automate a process isn’t necessarily as easy as we’d like it to be; but we also know that the process is complex, error-prone, messy, or otherwise not great to leave as a manual process.
\nPlaybooks are the middle ground I reach for in these circumstances. When I see a process like this, instead of either doing nothing or just diving in and writing some code, I’ll first write a playbook. A playbook is nothing more than a set of instructions for performing the task – a “recipe” if you will. The key is to be as specific as possible. If this is some sort of task that involves code, you can even include bits of code or shell commands that someone following the playbook could copy and paste.
\nThis gets a few steps closer to the goals of automation – consistency, repeatability, reliability – at a fraction of the effort. And, if you later decide that automation is worth the effort, the playbook serves as a detailed specification for your code.
\n
(Emphasis mine)
\nContext.
\nIt might be one of the words I use the most nowadays. \"Always give the context\", \"Start with context\", \"Can you give me the context again?\".
\nWhy? Because not having the context is like shooting in the dark. You can perform your task, but it will likely be wrong because you don't understand everything around it. If you are interested, this book is an illuminating read on this topic.
\n↩\nWhen I explain why I do this, I often say \"I'm helping Matthieu-du-futur\". It takes only a few very short seconds now, and saves hours of frustration and guesswork later.
\n↩\nAmidst the current crypto-crisis/downfall, I found this excellent interview of Nicholas Weaver by Nathan J. Robinson. The article is called “Why This Computer Scientist Says All Cryptocurrency Should “Die in a Fire””, and, as you can guess, is not really gentle with cryptocurrencies and the blockchain in general.
\nThe interview talks about many topics and is really interesting. Here's a few passages I enjoyed.
\nStarting with Nicholas Weaver, in 2018:
\n\n\nCryptocurrencies, although a seemingly interesting idea, are simply not fit for purpose. They do not work as currencies, they are grossly inefficient, and they are not meaningfully distributed in terms of trust. Risks involving cryptocurrencies occur in four major areas: technical risks to participants, economic risks to participants, systemic risks to the cryptocurrency ecosystem, and societal risks.
\n
Briefly quoted in the article, Jackson Palmer, creator of Dogecoin:
\n\n\nAfter years of studying it, I believe that cryptocurrency is an inherently right-wing, hyper-capitalistic technology built primarily to amplify the wealth of its proponents through a combination of tax avoidance, diminished regulatory oversight, and artificially enforced scarcity.
\n
In an exchange later in the article:
\n\n\nRobinson: “I am sure you have heard people say things like “Well, blockchain technology itself has lots of potential applications, it’s really interesting, offers lots of possible solutions to problems.” But one thing you point out in your lecture is that often, they are pretty vague about what these uses are, and usually when you get down to the facts, there’s a much simpler solution to whatever problem it is that wouldn’t use blockchain.”
\nWeaver: “The thing is, the idea behind a blockchain is actually a 30-plus-year-old idea. It’s called a hash chain. And we’ve known how to build these for longer than most of my students have lived. But people who spout “Blockchain!” don’t understand the technology. […] When somebody says you can solve X with blockchain, they don’t understand X, and you can ignore them.”
\n
Illustrated in this illuminating example:
\n\n\nSo, this was an example given by a purported expert in a blockchain class at Berkeley: “Okay, we have the cold chain problem. Vaccines, you need to ship cold, and if they ever get out of temperature spec, you have a ruined batch. And we can solve this with blockchain.”
\nAnd my reaction is: “No”. The problem is you need to know when it got out of spec, and know that the receiver can know that it had gotten out of spec. And there’s an easy solution. It’s called a $1 ShockWatch label. So the ShockWatch group makes these temperature labels. You stick them on the package. And if it ever gets too warm, the color changes. No blockchain necessary.
\nThe fact that somebody was purporting this to be a real-world application meant they had not even thought about the problem for five seconds.
\n
In another exchange:
\n\n\nRobinson: “One of the things you’ve said, if I recall, is that the cryptocurrency space is “speed-running 500 years of financial history.” By which I take you to mean that all of the financial disasters of centuries past are playing out in short order, and then they have to rediscover the solutions that were put in place for those things not to happen.”
\nWeaver: “Yeah. […] The thing is, though, the cryptocurrency space itself has the object permanence of a horny mayfly. They simply don’t remember their own scams.”
\n
Finally, Nicholas Weaver, concluding the interview:
\n\n\nThat’s the problem, and that’s why I’ve actually changed my view over the past decade. Back in 2013, I thought it was amusing and silly, and I could get cool papers out of it. In 2018, I thought it was amusing, but pretty bad. [In 2022], it’s time to really think about burning it down. Now I just want to take the entire cryptocurrency space and throw it into the sun. I know astronomers will tell you it’s easier to throw something into the void of space than to throw it into the sun. But it’s worth the extra energy to make sure some alien doesn’t find this mental virus.
\n
(Emphasis mine)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2022-06-30T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2022/04/iterative-loop/", "url": "https://matthieuoger.com/2022/04/iterative-loop/", "title": "Iterative Loop", "content_html": "\n\n\nTo make games, you have to walk through something called the iterative loop.
\n\n
\n- You have to have an idea,
\n- And you have to figure out how to build it into something testable
\n- And then you have to test it,
\n- And then you have to reflect upon it,
\n- And then you have to adjust your idea.
\nThen you complete the iterative loop, and you do it again.
\nAny designer will have to run around this iterative loop thousand of times before a game is completed.
\n[…] Figure out ways to move, to make that loop smaller. And to run though it more efficiently. Or you'll burn yourself out.
\n
(Slightly edited for readability)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2022-04-27T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2022/03/rotation-videos/", "url": "https://matthieuoger.com/2022/03/rotation-videos/", "title": "Pseudo-Intelligent Rotation Lock for Videos on iOS", "content_html": "iOS is missing one major, albeit a very small one in size, feature.
\nYou can use a rotation lock for your device, which restricts its ability to change orientation. By default, an iPhone senses when it is in landscape or portrait. This was one of the key features during the iPhone introduction (using an accelerometer). It looks very cool, but in reality, it's almost useless on a phone.
\nMost users are just using the portrait mode all the time, and the landscape orientation is often toggled by accident while in bed or couch.
\nThat's why many users are activating the rotation lock permanently (I'm in this category). This is how it looks like:
\n
When it's active (like in the screenshot above), your device will never rotate automagically. You can stay in portrait orientation forever.
\nThis is perfect, except for one thing: videos. Videos are the only thing you want to see in landscape, not portrait.1
\nSince tons of videos are consumed through YouTube, the problem is particularly egregious there. Fortunately, YouTube added a way to switch a video to landscape, even when in portrait orientation (by using the fullscreen button), locked or not.
\nIt's not as practical as physically rotating the phone though.
\nA few years ago, iOS' built-in Shortcuts2 app added \"Automation\" triggers.
\nWith this, you can program an action when something happens on your phone. For example, if you open a certain app, you can automatically trigger something… like enabling or disabling the orientation lock! You can see where we are going…
\nCreate 2 automations:
\nYou should have this by the end:
\n![\"Automations\"](\"/images/posts/2022-03-15-automation.jpg\" "\\"Automations\\"")
Thanks to this automation, I keep the rotation lock activated all the time, but still physically rotate my device to play videos in landscape.
\nThis trick is not new at all. It was feasible since iOS 13 or 14, so why am I talking about this? Until now, everytime the trigger would activate, iOS would throw an annoying notification:
\n![\"Notification\"](\"/images/posts/2022-03-15-notification.jpg\" "\\"Notification\\"")
Because of that, I could never recommend this tip to anyone. However, today Apple released iOS 15.4, which finally allows an automation to hide its notification.
\n
Now, let's hope for a real “Lock orientation except when playing videos” setting.
I was recently listening to an interview of Phil Libin, co-founder of Evernote. Tonsky wrote a recap covering the best parts (notably about the startup model, culture and diversity issues), that I recommend.
\nIn addition, focusing on the product management side of the interview, I wanted to highlight a few paragraphs.1
\n\n\nWe kind of figured out what really felt like a cheat code. […]
\nLet's say it takes 10.000 iterations to make a product great. You have to keep polishing, to keep refining and it takes around 10.000 iterations. The whole point is: how fast can you do each iteration?
\nAt my previous company [dealing with security software, bank, government, etc.] it would literally take a year and a half to do an iteration. [You were making] some software, [sell it to an entity], deploy it, [deal with pilots], have a formal feedback. If it's gonna take a year and a half to make improvements to the product and you need to make 10.000 iterations, it's fifteen thousand years to make a great product. You just don't have this kind of time.
\nAt Evernote […] an iteration was twenty minutes, because we would just make something — and then, if we were honest with ourselves —, we could say \"does this feel better or worse than it did twenty minutes ago?\". And so, by having this really fast, really tight iteration loops […] we could just move really really quickly. We could make a product pretty good faster than I ever thought possible before.
\n
And, as a consequence, the time to make a product great (not just \"pretty good\") is also reduced.
\nOne note though: we need to be careful not to confuse \"speed of iteration\" with \"velocity\".
\n\"Iteration\" is your ability to experiment and refine a feature. You can iterate a lot but just release a very few impactful features (which is good). To the contrary, you can iterate slowly and output a lof of very low value, unpolished and mediocre features.2
\nSpeed of iteration is important.3 Meaningless velocity is not. It's more debt, it's harder to maintain, and it results in more complex products for users.
\nSee “Stop Obsessing Over Development Velocity, Focus on This Instead” for a good \"factual\" overview.
\n\n\nIt isn't so much that we didn't listen to our users. We listened to our users very carefully but in a very specific way. We listened to how they were reacting to what we were putting in front of them. We weren't asking them about what they wanted. […]
\nIf you ask users what they want, they are not gonna tell you what they want because they don't know. Very few people can articulate and have the power of imagination to envision what they actually want.
\nIf you ask customers or prospective customers what they want, they'll tell you the stuff that they expect… and very rarely will that actually be what they want. [Then, he quotes Henry Ford famous line: “If I had asked people what they wanted, they would have said faster horses.”]. We don't ask customers what they want, we ask customers to respond to what we are giving them. Because then, it's much more useful: you can tell when people are confused, when they are happy, when they are satisfied and then we can decide who to ignore, which opinion to take seriously, etc.
\n
This is one of the topics I'm coming back to frequently in my job.
\nHow can you gather as much feedback as possible, while not becoming crushed by its weight or clients' expectations?
\nMoreover, collecting the feedback is only one side of the coin (and the easy one). The second side is how to digest it properly. There, you discover that the product manager's toolkit is, unfortunately, very empty.4
\nUsers feedback are critically important insights, but it should be seen as an additional knowledge base for future decisions and hypotheses. Not as something you must respond to — or worse, act on — constantly.5
\nSee also “Build with users” from the Linear method.
\n\n\n[About Evernote] I think we just did too much stuff. There's always this balance of “what's the right amount of focus?”.
\nIt's hard to know in the moment… you can only do that in hindsight — if you succeed, you had the right amount of focus. If you don't, then you are either doing too much stuff, and you didn't have that focus, or not enough stuff, and you weren't thinking big enough or whatever.
\nWe always struggle with that balance. What is too much to build and what is just the right amount? How do we know? […] In hindsight, I would have worked for longer on some specific things before moving on to introduce [new features].
\n
This reminds me of a comment made by a candidate during an interview: “One crucial part of a product manager's job is not about which features should be included, but which one should be removed or ignored” (paraphrasing).
\nI slightly edited Phil Libin's speech to make it more readable in a written form. Emphasis is also mine.
\n↩\nUnfortunately, most agile teams using Scrum are optimised toward extreme-velocity instead of their ability to experiment and iterate quickly. Which is not what agile was about initially. I blame consulting firms.
\n↩\nIt's why we need to be able to deploy often, quickly, automatically, and confidently. It's also why the development pipeline loop should be as short as possible, between typing the code and observing the results.
\n↩\nI've searched for many, many tools to handle feedback. I didn't find one that was 100% satisfying. At this point, I'm considering there is no \"right\" solution to this problem.
\nThe most adequate tool is probably a generic data-visualisation or log processing platform like Kibana or Datadog. Tools that were not conceived for this problem specifically, but instead to digest, process, present and search raw data in quantity. Which is what user feedback is: information logs, but provided by users instead of machines.
\nSee it similarly to an analytics tool: you would consult the platform everyday to have an overview of your users, how they feel about your product, and what they expect. Use that as additional data for experiments and ideas. When you look at analytics, you don't act immediately, and you cannot answer questions there. You use this trove of data to refine your hypotheses. Feedback should be seen the same way.
\nUsing this approach would also remove the emotion from the equation. It would allow the product manager to take a step back and look at all this knowledge objectively… like analytics.
\nAnd for qualitative measures? Just run some real-life user tests and sessions.
\n↩\nI think there's something profoundly wrong in the B2B (less so in B2C) world, where clients expect to have answers to everything they ask or want.
\n↩\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-12-14T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/08/the-experience/", "url": "https://matthieuoger.com/2020/08/the-experience/", "title": "It's the Experience", "content_html": "\nI’ve heard my favorite engineers claim the reason they are productive is because they are lazy. It’s a humblebrag. These humans don’t have a lazy bone in their bodies. What they appreciate is efficiency. I want to design this system so I only have to do this once.
\nSetting up the initial conditions and letting the work just happen.
\n
\n\nI see stuff like this every day. Companies 'trust the analytics'.
\n\"99% of users complete the page, so it's not a problem\".
\nBut the issue isn't the completion rate, it's the experience.
\nThis example might only be a small confusion, that most people would overcome on their own, but it makes the experience less enjoyable.
\nThe more enjoyable an experience, the more we want our friends to do it.
\n
It's a problem I see in many products and videogames. A videogame can have a fantastic retention score, but it does not make it fun.
\nI'm not against analytics (quite the contrary, if done respectfully), but it should not be your main driver. It should be a source of advices and confirmation to qualitative analysis, insights and/or gut feelings. It should be secondary to the experience itself.
\nSometimes, you should do something because it makes your product better and more pleasant, not because it checks another item on an imaginary features checklist or because it pleases one specific client.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-08-31T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/05/abstract-digital-product-design/", "url": "https://matthieuoger.com/2020/05/abstract-digital-product-design/", "title": "Digital Product Design", "content_html": "I watched the first season of Abstract on Netflix a few years ago when it was first released. It's a really fascinating series about design — in its broad definition — illustration, digital, industrial, photography, painting, etc.
\nA second season was recently released, and I'm slowly watching the new episodes.
\nThe one about “Digital Product Design” is, obviously, particularly interesting to me. I've extracted a few highlights below.
\nIan Spalter in “Digital Product Design”:
\n\n\nWhen I start a new project, the first thing I do is to define the problem, to understand the “why” of what we're trying to do and what is the thing we're trying to solve for?
\n
See also this article entitled “Great PMs don’t spend their time on solutions” by Intercom, and this quote by Marty Cagan:
\n\nFall in love with the problem, not with the solution. […] It's far too easy to fall in love with your particular approach and lock yourself in prematurely.
\n
Ian Spalter:
\n\n\nYour stove has a UI.
\nSo what conventions are out there in the world that you should take advantage of? You don't want someone to think too much about heating a pan. But then, sometimes there are opportunities to improve things.
\nMaybe it's about adding options that make sense.
\nSo, I have a toaster that has a button that says “A bit more” on it. It literally says, “A bit more.”. Totally get why you would need that, right? 'Cause that's… that's part of the user experience of making toast.
\n[…]
\nNow, as a designer, there are costs to that, because now you added a new button. Is it worth it? Is it actually valuable? Is it something that people use, or is it just sort of superfluous, you know, and just, like, maybe sell some toasters.
\nThat's all part of the experience, thinking about the conditions and the context. And then, how do you work within those constraints to make that task as easy and pleasurable as possible?
\n
Ian Spalter:
\n\n\nThat idea of creativity being born through constraints is a powerful one.
\n
Robbie Gonzalez:
\n\n\nIf you've ever been scrolling through your Twitter feed or your Instagram feed, you've noticed you don't hit the bottom. That's a relatively new feature, called bottomless scroll.
\n
Aza Raskin:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-05-17T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/05/the-component/", "url": "https://matthieuoger.com/2020/05/the-component/", "title": "The Component", "content_html": "Which I feel like I have to forever atone for. When I was thinking about infinite scroll, like, the thought was… I, as a designer, have failed if I ask the user to make a choice they don't care about.
\nSo, scrolling already means “I haven't seen what I want, show me more.”
\nSo, why bother having little buttons at the bottom that you click to show — show more?
\nI as an individual designer doing human–computer interaction will happily make an infinite scroll.
\nBut if I'm thinking at this higher level, I would have known that that would remove the stopping cues, just like when I'm drinking a glass of wine. I stop drinking when I finish my glass, and I think “Do I want more?”. Here, we're not giving people the stopping cue.
\nAnd so it's literally wasted hundreds of millions of human hours.
\n
Guillermo Rauch in the “Vercel” announcement (previously Zeit):
\n\n\nToday the most interesting new opportunities for modernization have shifted to the frontend. […]
\nComponents Are the Right Primitive for the Frontend
\nAs the demand for richer frontend experiences has grown, the pressure is for teams to deliver component and design systems - coherent frontend experiences across every platform. […]
\nNot too long ago, people weren’t talking about components, they were talking about selector engines and the DOM. Then React […] introduced this primitive of the component. Other frameworks allow you to define components, but the movement that really pioneered this trend was React.
\nYears ago, [we] created Next.js because of our belief that React was so powerful it could become the full engine for the frontend. We started Next.js to provide some critical new functionality to make React consumable for everyone who wanted to do everything with React, instead of just one specific component. We saw a demand for the component-based React approach to drive the full frontend experience.
\n
I really love small, hyper-optimized websites with just the necessary bits (I really enjoy reading people writing about this topic). I did that for years. This is how I taugh students.
\nBut using React made me reevaluate my tradeoffs slightly1.
\nComponents and declarative coding are such a better programming model. React nailed that. It's far from perfect, and some stuffs are way too complicated, but the basis is right. The foundations are correct.
\nTom MacWright in “Second-guessing the modern web”:
\n\n\nThe emerging norm for web development is to build a React single-page application, with server rendering. The two key elements of this architecture are something like:
\n\n
\n- The main UI is built & updated in JavaScript using React or something similar.
\n- The backend is an API that that application makes requests against.
\n[…] There is a sweet spot of React: in moderately interactive interfaces. […] The high performance parts aren’t React. […] The low performance parts don’t need to be React. […]
\n
Later:
\n\nDon’t read this as anti-React. I still think React is pretty great, and for a particular scope of use cases it’s the best tool you can find. […]
\nBut I’m at the point where you look at where the field is and what the alternatives are – taking a second look at unloved, unpopular, uncool things […] – and think what the heck is happening. We’re layering optimizations upon optimizations in order to get the SPA-like pattern to fit every use case, and I’m not sure that it is, well, worth it. […]
\nFrameworks should lure people into the pit of success, where following the normal rules and using normal techniques is the winning approach. […] I don’t think that React, in this context, really is that pit of success. A naïvely implemented React SPA isn’t stable, or efficient, and it doesn’t naturally scale to significant complexity.
\n
Very true, unfortunately.
\n
After:
\n\nI can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.
\n
This is undeniable. But perceptually, it's not necessarily the case nor that simple.2
\n
Finally:
\n\nI don’t think that everyone’s using the SPA pattern for no reason. For large corporations, it allows teams to work independently: the “frontend engineers” can “consume” “APIs” from teams that probably work in a different language and can only communicate through the hierarchy. For heavily interactive applications, it has real benefits in modularity, performance, and structure.
\n
If I chose to build my new websites with Next.js or Gatsby, it's because working with styled-components and React is so much better, fun and faster. And the result can be great for the users too, if done well.3
\nIn the end, there's no good answer here. There are just many tradeoffs (accessibility, customer experience, speed, team collaboration, developer experience, bandwith, performances, etc.). And, as always in computing, there's no “ideal solution”.
\nNot coding in my day-to-day job also changes my priorities. Creating websites is a hobby now (and was not the main focus of Pixelnest anyways), so I value my time and enjoyment much more.
\n↩\nFor example, this website (Gatbsy, React, SPA) is heavier, but feels faster than Pixelnest's (Jekyll, no-JS). It's slower on first and initial uncached load, but after, it becomes faster — almost instant.
\n↩\nJust imagining having to write BEM classes, put everything in big files, or repeat so much HTML would feel like going back ten years ago.
\nI actually did that recently, and it was not horrible. But it becomes a mess much more quickly, especially if you are working with more junior developers. You need even more discipline and rigor. It's possible for a one-man website, but it can break quickly as you add more people on a project if the experience level differs a lot.
\n↩\nSuperhuman in “Blazingly Fast, The 100ms Rule”:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-05-06T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/05/in-search-of-software-magic/", "url": "https://matthieuoger.com/2020/05/in-search-of-software-magic/", "title": "In Search of (Software) Magic", "content_html": "The creator of Gmail, Paul Buchheit, had a rule: every interaction should be faster than 100ms.
\nWhy? Because 100ms is the threshold where interactions feel instantaneous.
\n
From Linear's README, “In Search of Magic”:
\n\n\nSoftware used to be magical. We were excited about the new possibilities it opened up.
\nAs the decades went by, software became more common. It became a larger part of our lives and an important part of how the world operates.
\nToday software is everywhere, but it’s become increasingly rare to encounter truly great software. Computers are faster but apps work slower. Corners are cut with each release. Product decisions are driven by A/B tests.
\nWe’ve lost the magic along the way. And the result is software that’s frustrating and boring to use.
\nWe want to bring that magic back.
\n
Then:
\n\n\nLinear was born out of our own frustrations in building software projects in successful high-growth companies. We saw the effects of subpar tools and practices in our teams, so we decided to build something better.
\n[…] We’re creating software for teams who want to create impact. We think the software you use every day to work should be of the highest quality. It should feel exciting and enticing. It should be fast. And you should feel empowered when using it. Professional tools should have professional quality.
\nWe truly believe that the tools teams use directly impact the outcome of their work. Bad tools encourage bad habits. Good tools encourage good habits.
\nThe tools we use should make us more powerful and help us to accomplish our goals. […]
\n
Finally:
\n\n\nWe believe that the quality of software is driven both by the talent of its creators and how they feel while they’re crafting it. Teams that are excited, engaged and proud of their work build better software.
\n
I've rarely read a company's vision this good and exciting. And, damn, their website looks so nice.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-05-05T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/04/outcome-successful-strategy/", "url": "https://matthieuoger.com/2020/04/outcome-successful-strategy/", "title": "The Outcome of a Successful Strategy", "content_html": "Vjeux in “Make the game easy”:
\n\n\n[About building software] When I see people doing very visible and consequential actions, I find myself thinking that they are doing a “hero shot” and it must mean that they got “out of position” for the past few shots and now the only option that they have left is unsatisfying but there’s no other choice.
\nOn the other hand, I see people appearing to somehow always be in easy projects where everything just works out fine and they deliver a lot of impact. I used to think that they were lucky, now I think that they are pro players and are able to plan multiple shots in advance and able to execute on their strategy.
\n
It's like the \"sysadmin paradox\".1
\nA great sysadmin is someone who seems to do almost nothing: the stack is functioning as expected, there's no outage (or really short ones), the software is updated, developers are autonomous, and all the processes and deployements are automated and painless2. This sysadmin is never too busy, answers quickly and acts fast. There's nothing extraordinary happening: it just… works. Almost too easy?
\nA bad sysadmin will always be on the rush. Though… they do look busy.3
\nBrett Terpstra in “Judging the value of automation”:
\n\n\nI enjoy the process of building automations in myriad contexts, using myriad tools. […]
\nI often think about the benefits of automation in the context of time savings. It makes things more efficient, removes drudgery. But I’ve realized over time that the real benefit of automation is avoiding mistakes.
\nWhen I automate something (anything), I’m defining the steps that need to be included to complete the task. I’m no longer relying on my memory to ensure that every step is complete or the specific ways in which a step should be completed. This is especially useful if it’s something I don’t do very often […] if it helps me do the exact same thing one time a year later, that’s often worth as much as any amount of total time saved in my life.
\n
Exactly! Avoiding mistakes is much more important than any time-saving1. Automation removes the need to remember what you need to do, and simplify the sharing of knowledge. It's basically a self-fulfilling checklist that can be triggered by anybody.
\nWhen I was developing a new website for Pixelnest Studio, the first step was setuping the project, and automating the deployment, so that I could come back 6 months later and still be able to deploy easily without reading the README or the code.
\nFor Steredenn, I created a lot of scripts to automate the release pipeline (building the game, packaging it, creating the different changelogs for the multiple platforms, etc.). This took me a non-negligible amount of time, but when I needed to do a new release after a long hiatus, it was a breeze and such a relief. Bonus: my associate could also do it in case I was not here, without having to dive in the code or knowing the full process.2 In the game itself, Damien spent time creating little tools and helpers to go to a specific part of the game easily, so we could test different configurations and situations at will. The result? A better, more stable game. Less mistakes. More time.
\nI maintain a personal repository with most of my non-app scripts on GitHub, and one of my most treasured part is a procedure to boostrap a new macOS installation in a semi-automated fashion. I don't do that often, but I know that I can confidently reproduce a new environment (in case of loss or theft) without a lot of struggle.
\nI tried to put most of the settings of my apps (Alfred, iTerm2, Dash, etc.) on a cloud provider, so that I can share them between computers and have a backup (it's actually one of my selection criteria when I try a new tool — \"can I sync the settings easily?\"). The tools are tailored to my use, and I don't have to customize them again.
\nI automated and documented our servers installation so that I could nuke and reinstantiate them easily. I'm not an experienced sysadmin at all, so having this ability to restart from scratch was a godsend to me.
\nIt's not pure automation, but it falls in the same ballpark for me. It's emptying your brain so that you can focus on what you care. And, bonus, it's fun to do!
\nAs a different example: I scan and store all my documents online (pro or perso). When I'm asked for something (passport? last phone bill?), I take my phone, get the document and send it or print it directly.
\nIt's a really simple process: when I receive a paper, I quickly look at the document, decide if I keep it or not (if not, it's direct in the trash), then launch Scanbot, OCR it and boom it's stored in the right place. It has just become automatic for me now. It takes me literally 10s. And this has saved me so. much. time, as well as prevented the loss of important stuffs. It would have been easier to just put that doc on a shelf and never care about it anymore, sure. But then, when you search for a new flat, and need to find those twenty docs, you will thank yourself.
\nIt was always more effort initially, and we, humans, don't like effort. But being a good slacker is not about doing nothing, it's actually doing more at the beginning, so you can do less later. And that's what computers are good at too!
\nThat's also a reason why I love checklists so much. Checklists are the manual version of automation: you write it, you duplicate it, you cross it, and you forget it.
\nChecklists are also cheap and easy-to-write documentation — for you, your family, your friends, your coworkers.3
\nIn computing (and life in general), there are a few principles that I consider extremely important and I'm trying to apply as much as possible:
\nThat's automation, although at a bigger scope than just plain computer automation and scripting. That's why I like to be organized and to create systems8 in my life9 (and not only on my computers). It's a way for me to be consistent, coherent, efficient and meticulous. To care about what I do without putting more charge on me.
\nAnd to be able to lose my time on the areas where it provides me joy.
\nWhich is still a really nice perk — we shouldn't diminish that property.
\n↩\nDon't get me wrong: it was not perfect. Some steps were still manual and I could have automated them, but there's a point where a good ol' checklist is enough and automating becomes a burden. However, if it's manual, it needs to be documented. Hence, generally, a checklist.
\n↩\nYou go on a trip? Write your packing checklist. Quickly scan it before leaving a place — you won't lose anything.
\n↩\nThat can be a script, a documentation, or a process. That's why, when I find an important information, I store it ASAP in my Dropbox so I can come back to it later. That's also why I'm blogging: to keep the relevant articles I found right at my fingertips. That's, finally, why I love scripting: I don't want to memorize how I need to execute an action — without scripts, it's more mistakes later, and less predictability. There's also a nice side-effect: it's an additional (and versioned) source of examples.
\n↩\nThat's why automation-freaks enjoy text expansion so much. But it can also be optimizing your commute route, or always putting stuffs at the same place in your flat so you don't have to think to locate them.
\n↩\nThis article showed that I like anecdotes. Here's another: when you have a company in France, you need to do something called \"l'approbation des comptes\" every year. It's boring, complex, and prone to mistakes. The first time I did it, I noted all the steps I needed to do while I was learning to do it. The next year, it — obviously — happened again, and I didn't have any clue about what I did. I remembered taking the notes, look at them, and in almost no time, was able to do it again. I could have learned once more, but this would have been a big waste a time, and a big chore. Instead, it was just a minor annoyance.
\n↩\nIf I hear someone talking about a thing they like, I note it. Later, when I need to find a gift, I can look at the list and pick there. It is not always useful, nor something you can do rightaway… but people are so happy when you give them something they actually truly wanted. It's also less waste.
\n↩\n\n\n↩\nThis also just speaks to the power of habits, because, changing a habit is like overwriting your current software, and if you do it enough time, what's cool about your brain is, it rewrites it to accommodate the new behaviour. You're saying \"oh, I guess we are doing this everyday now?\".
\n
Or as someone said: \"have a reset button for my apartment\". Everything has a spot, and in the mornings, when you wake up, you put everything back to its rightful place. It's always the same, it's easy to clean, it's easy to find if something's missing. It does not preclude change, but change should be desired and aware, not the byproduct of chaos.
\n↩\nMarty Cagan in “Epic Waste”:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-04-23T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/02/tools-as-superpowers/", "url": "https://matthieuoger.com/2020/02/tools-as-superpowers/", "title": "Tools as Superpowers", "content_html": "[…] What I believe is the largest source of waste in technology, and that’s waste in large companies. I’m not talking about large technology companies like Apple and Amazon and Google [but] about the thousands of large banks, insurance companies, airlines, auto manufacturers, telcos, retailers, health care providers, and entertainment companies, that spend shocking amounts of money on technology every year for such paltry results.
\n[Visited multiple companies] from each of these industries and with precious few exceptions, I find these large “IT” organizations, usually run by CIO’s or CFO’s, and operating with horribly inefficient and ineffective methods. They are typically using stakeholder-driven roadmaps, project-based funding and staffing, heavy use of contractors and outsourcing, waterfall processes (even when they claim they’re Agile), no effective product role, and minimal if any UX design. […]
\nThe amount of waste at these companies is staggering. The irony is that they often believe they’re actually saving money. […] They don’t understand that their model is requiring much larger teams, and more importantly, they are not able to operate at the speed of innovation […] Because these leaders don’t understand technology, they make short-sighted decisions and then struggle to connect the dots between their choices and the poor results.
\n
Jonathan Lefèvre (loosely translated from French1):
\n\n\nThe topic of scale is as inevitable as it is hard, and seems so at odds with the human customer service idea, difficult to automate just by its own definition. Even the enterprises for which customer service is not a priority can find themselves confronted to the exact same problem. All of them must think about the best organization possible to handle efficiently the endless influx of requests and questions.
\n[…] But this has mostly allowed me to realize what was truly making the strength of the customer service at Capitaine Train: its operational efficiency. In the end, if we could manage 2 millions of customers with a small team of 15 people, it was because we were extremely well equipped.
\nNothing was left to chance in the hunt for the lesser and useless click. And if this constant quest for the optimization of the processes is a topic that interests many entrepreneurs, I think that it manifests itself in an even more glaring way when you do customer service management of a start-up in hyper growth. […] When you spend days fighting the steamroller of client requests, you inevitably finish to devote a cult to any tool able to make you gain the smallest second of productivity.
\n[…] So, I imagined naively that any customer service in the world would use the best tools in the market to work more efficiently. I was far from the mark. Numerous were those that didn't have a good system to manage notes and documentation, the basic and elementary reflexes to minimize interruptions, or just a sane way of handling emails.
\n
In general, adding more people and asking them to work more is not the right way to solve a problem — I would even say it will create the opposite effect in the long-run.
\nI really like this article because it shares perfectly my vision for productivity and tooling. Tools are humans' superpowers. We need to harness them — and give tedious jobs to machines. Humans are good at creativity and thinking, but particularly bad at doing constant and repetitive tasks.
\nThough, and like the author, when I say \"productivity\", it's not as a synonym for pushing people to always work more and to exhaust themselves (which is unsustainable and not right), but the contrary: doing more things, with less effort and time. The end-goal is to work less (or not all), enjoy the present, improve quality of life for everyone, while still being able to deliver great services and products for an healthier society. In that sense, computers are the great enabler of this vision.2
\nOriginal version:
\n\n\n↩\nLe sujet du scale est aussi inéluctable que difficile, tant il semble peu compatible avec la notion même de service client humain, compliqué à automatiser par définition. Même les entreprises pour qui le service client n’est pas une priorité se retrouvent forcément confrontées à ce problème. Toutes doivent réfléchir à la meilleure organisation possible pour gérer efficacement ce flux incessant de demandes.
\n[…] Mais elle m’a surtout permis de prendre conscience de ce qui faisait véritablement la force du service client de Capitaine Train : son efficacité opérationnelle. Au fond, si nous arrivions à gérer 2 millions de clients avec une petite équipe de 15 personnes, c’est parce que nous étions très bien outillés.
\nRien n’était laissé au hasard dans la chasse au moindre clic inutile. Et si cette constante quête d’optimisation des processus est un sujet qui intéresse beaucoup d’entrepreneurs, je crois qu’elle se manifeste d’une manière encore plus criante lorsqu’on fait du service client dans une start-up en pleine croissance. […] Quand on passe ses journées à affronter le rouleau compresseur des tickets clients, on finit par vouer un culte à chaque outil capable de nous faire gagner la moindre seconde de productivité.
\n[…] Du coup, j’imaginais naïvement que tous les services clients du monde utilisaient les meilleurs outils du marché pour travailler plus efficacement. J’étais pourtant loin du compte. Nombreux sont ceux qui n’ont pas encore un bon système de prise de notes, les réflexes élémentaires pour minimiser les interruptions, ou encore une gestion saine de leurs e-mails.
\n
It's probably utopian, I know.
\n↩\nWe were waiting in a rented car while being in a small town in the East of France. A town without charm. We had to stay here for one more hour before going to the wedding we were attending.
\nBored, with nothing special to do now that we had visited the city, I browsed a bit on YouTube. I fell on a video by Tim Ferriss which looked kinda okay — I didn't know the guy that much, except that he was the host of a famous podcast which never interested me particularly.
\nIt was about \"defining fears instead of goals\". The video was around 15min, so I launched it. It started weirdly. The guy was talking about a suicide attempt, and the tone was dark, and at the same time, he was also joking.
\nMy girlfriend was next to me and I heard a \"what are you watching?!\" with a dubitative look. I continued.
\nSurprisingly, I still think about this talk regularly, even 7 months later. This is what I kept in mind:
\n\n\nIn the Greco-Roman world, people used stoicism as a comprehensive system for doing many, many things. But for our purposes, chief among them was training yourself to separate what you can control from what you cannot control, and then doing exercises to focus exclusively on the former. This decreases emotional reactivity, which can be a superpower.
\n[…] And I did find a quote that made a big difference in my life, which was, \"We suffer more often in imagination than in reality,\" by Seneca the Younger, who was a famous Stoic writer.
\n[…] \"The Cost of Inaction.\" Humans are very good at considering what might go wrong if we try something new, say, ask for a raise. What we don't often consider is the atrocious cost of the status quo -- not changing anything.
\n[…] And the last was his mantra, which he applies to everything, and you can apply to everything:
\n\"Easy choices, hard life. Hard choices, easy life.\"
\nThe hard choices -- what we most fear doing, asking, saying -- these are very often exactly what we most need to do. And the biggest challenges and problems we face will never be solved with comfortable conversations, whether it's in your own head or with other people.
\n
Initially, we were not sure what to think of this. Then, we discussed a bit. This sounded so logical, so simple, so obvious. But yet, thinking in these terms was really eye-opening.
\nThis talk is weird, disconcerting, with a strange tone and discourse. A bit pompous, especially with the business references distilled inside some really horrible anecdotes. But I would still recommend to watch it.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-02-09T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2020/01/japan-pizza-culture/", "url": "https://matthieuoger.com/2020/01/japan-pizza-culture/", "title": "Japan Pizza Culture", "content_html": "Matt Goulding in “Slice of Tokyo: How Japan Became a Pizza Hotspot”:
\n\n\nAfter passing my final exam before a panel of Naples’ old guard of pizzamakers, I asked the judges who else, besides the Italians, were making good pizzas. Most just smirked and ignored the question, as if it had no reasonable answer. But one of the older gentlemen waited until the conversation moved on before waving me in close:
\n“Don’t tell anyone I told you this, but the Japanese are making better pizzas than we are.”
\n
I had, indeed, a wonderful Margherita at Seirinkan while I was in Tokyo three years ago.
\nRelated, from one of my favorite essays by Craig Mod on the same subject, “Tokyo Neapolitan: The New Wave of Japanese Pizza”:
\n\n\n“Pizza shops are not quite like bakeries, not quite like restaurants — everything comes together in a single moment; 60 seconds determine the success or failure of a meal.”
\n[…]
\nIt turns out the decision to pre-cut a pizza comes with its own philosophical underpinnings
\nInoue believes that because a pizza is not perfectly symmetrical in terms of ingredient distribution, each slice is inevitably a little different; there's no way to cut a pizza in a way that perfectly captures its entire essence in a single slice. His ideal is for one person to eat an entire pie on their own, ensuring they experience the full spectrum of flavors.
\n
And also slightly related, a more recent one by the same Craig Mod: “I Walked 600 Miles Across Japan for Pizza Toast”.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2020-01-22T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/11/speaking-interface/", "url": "https://matthieuoger.com/2019/11/speaking-interface/", "title": "Speaking Interface", "content_html": "\n\n\nNow, my clients weren’t this bad, but look — you don’t need to be Bret Victor to understand that if you can only select ONE thing from a list, you need RADIO BUTTONS, not checkboxes. To understand that, you just need to be able to speak interface. And that’s the craziest thing to me. Interface fluency is something anyone can achieve. You don’t need college, you don’t need Lambda school, yadda yadda.
\nFrankly, you just need the presence of mind to (A) pause every single time you’re confused or frustrated by some app, (B) verbalize what about the interface makes you confused/frustrated/etc., and then (C) figure out how you could avoid that specific snafu in your own designs.
\n
A million times, yes.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-11-15T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/11/singapore/", "url": "https://matthieuoger.com/2019/11/singapore/", "title": "Singapore", "content_html": "I had the chance to go to Singapore twice recently. The first time was in June for one week, and the second time in the last two weeks. It was for work, but all in all, I still had almost 3 full week-ends to discover the city properly.
\nSingapore is really incredible. It's full of surprises, with gigantic skyscrapers, mind-blowing structures and some ancient places hidden inside the districts (although not as frequently as what you can find in Japan, for example).
\nIt mixes many asian cultures. The official language is English, but many others are spoken everywhere (chinese, indian, malay, indonesian, etc.). Food is available in abundance and diversity1. The city is really busy during the day (a lot less at night in my opinion), and everything seems to change quite often (eg. governement and companies are not afraid to tear down a building to build another one 10 years later). Men presence is omnipresent: new lands are created on the sea, and nature is tightly contained. It's fascinating, even though the country is an environmental aberration (overuse of air conditioning, for example).
\nThere's no season, and it's always the same weather: 28-32°C (probably around 40°C felt), warm, extremely humid, and cloudy with occasional rains or thunderstorms. Even at night (which starts around 19:30), it will still be warm (just 2-3°C cooler if you are lucky). You could be in short and t-shirt all year, and if you stay 30 min outside, you'll inevitably sweat.
\nThere are tunnels and malls everywhere, so if you want to avoid the heat, you just have to go inside a building to cool down2, \"thanks to\" the overabondance of AC3.
\nFinally, Singapore is really, really, safe. As a man, I don't feel unsafe most of the time, but still, you can feel the difference there. It can be 3:00 at night and you'll never feel threatened. You can forget something and go back one day later and find it again. It's when you go back home that you can really grasp how nice it is to walk so peacefully.
\nSome places I went to:
\nThere are many other places I still need to do (Little India, Pulau Ubin, a few temples, MacRichie, etc.). And I still didn't try a Kaya toast breakfast… That will be for another time!
\nJust try a Chicken Rice or black or white Chai Tow Kway (Carrot Cake) if you want something \"typical\".
\n↩\nIn an interesting way, I would compare the city to Montréal during the winter - you can navigate almost exclusively in man-built structure to avoid the harsh weather, but in Singapore, it will be from the heat, not the cold and snow. And all year, not just the winter.
\n↩\nIt often happens that it will be too cold inside buildings.
\nIt's also probably one of the reasons behind the economical success of the country:
\n\n\n↩\nITV: Anything else besides multicultural tolerance that enabled Singapore's success?
\nLee Kuan Yew: Air conditioning. Air conditioning was a most important invention for us, perhaps one of the signal inventions of history. It changed the nature of civilization by making development possible in the tropics.
\nWithout air conditioning you can work only in the cool early-morning hours or at dusk. The first thing I did upon becoming prime minister was to install air conditioners in buildings where the civil service worked. This was key to public efficiency.
\n
Tipping is such a stupid custom. The sole purpose is to not pay the employees correctly by default. Include the cost of the salaries in the f* price, and boom, done. Period.
\n↩\nThere's actually a Hell Museum inside, btw.
\n↩\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-10-13T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/09/software-disenchantment/", "url": "https://matthieuoger.com/2019/09/software-disenchantment/", "title": "Software Disenchantment", "content_html": "So security, obviously, and authentication, these are complicated topics, and they are complicated to engineer, they are complicated to explain. But I think, for security to be effective, and maybe this sounds a little too simplistic but bear with me.
\nFor security to be effective, it needs to be used, and for good security practices to be used, they need to be nice, they need to be elegant, they need to be clear.
\n[…]
\nIf you are a security engineer, you are gonna say \"who cares about being nice, it needs to be secure\", yes! It also needs to be nice! […] You need to understand that being nice is just as important as being secure, because if it's not a nice experience, people are just not gonna care and they are not gonna use it, and they are just gonna click \"OK\" and they are not gonna know what it means. So, is it really more secure… if it's not nice?
\n
Nikita in “Software disenchantment”:
\n\n\nSo everything is just a pile of barely working code added on top of previously written barely working code. It keeps growing in size and complexity, diminishing any chance for a change.
\nTo have a healthy ecosystem you need to go back and revisit. You need to occasionally throw stuff away and replace it with better stuff.
\n
See also: “The Sad State Of Web App Deployment” and “Something Slightly Less Terrible”.
\nI think the article is a bit short-sighted, and even wrong on some points: there's a difference between today's software and the one from 10 or 15 years ago — we do have progress. But the overall sentiment is fundamentally correct.
\nSomething is broken, and that's probably because we are still using code to build software.
\nThere's also a slight contradiction when he says we need to delete code, but still need to be able to run things from twenty years ago. If we were more thoughtful with what we build, it could be possible, but to keep a sane and manageable codebase in our current world, we need to accept that we will lose compatibility and devices over time.1
\n\n\nThat is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.
\n
I'm also guilty of that. Look, this website uses Gatsby to generate a few static pages, and this requires 242M of dependencies to build it (not run it, hopefully).
\nHowever, the result is extremely fast and satisfying for the user, and the developer experience is top-notch, at the expense of an increase in size of the exported bundle on initial (and uncached) load. Is this a reasonable tradeoff?
\nAt the end:
\n\n\nBusiness won’t care. Neither will users. They are only learned to expect what we can provide. We (engineers) say every Android app takes 350 MB? Ok, they’ll live with that. We say we can’t give them smooth scrolling? Ok, they’ll live with a phone that stutter. We say “if it doesn’t work, reboot”? They’ll reboot. After all, they have no choice.
\nThere’s no competition either. Everybody is building the same slow, bloated, unreliable products. Occasional jump forward in quality does bring competitive advantage (iPhone/iOS vs other smartphones, Chrome vs other browsers) and forces everybody to regroup, but not for long.
\nSo it’s our mission as engineers to show the world what’s possible with today’s computers in terms of performance, reliability, quality, usability. If we care, people will learn. And there’s nobody but us to show them that it’s very much possible. If only we care.
\n
On this, I don't completely agree. Yes, in general, people are mostly stuck with what we provide, but users are way too forgiving, and most of the time, don't even see the quality problem2 — only a fraction perceives it.3 Even engineers working on products don't necessarily see that something's wrong. How many engineers don't care about design, visual consistency, coherence, and speed, for example?4 How many don't see that their users are struggling?
\nBut there's a choice to be made by users: choose carefully, invest and learn, accept to spend a bit more on something better and more durable, change less often, and don't restrict yourself to the most ugly and cheap solution all the time, just because that was the first and easy choice.
\nThat's a shame and such a waste, though. I don't know if we can do better with our current tools.
\n↩\nCase in point: Windows is still a complete mess — the average bar of software quality on this platform is abysmal, and most people are completely okay with that — they don't even care. The only thing that raised the bar on Windows is Electron apps, and these came with their own set of tradeoffs, and are almost universally considered as subpar and second-tier citizens on other OSes. It's a vicious cycle: if the platform owner doesn't care, the developers won't care, thus the users too.
\n↩\nThis, though, poses another question: should we care about high quality if it doesn't matter for 80% of the users? I do think we should and I'm happy we still have craftsmanship in this world, but maybe it's only us, designers and nerds, that spend too much time pondering about that.
\n↩\nAnd it's a bit easy to say this without knowing the business constraints. Our society pushes for fast at the expense of doing things right and correctly — by taking the time. This gives us progress at an incredible and ruthless pace, but also a ton of waste.
\n↩\nStephen Wilkes in “The Passing of Time, Caught in a Single Photo”:
\n\n\nEinstein described time as a fabric. Think of the surface of a trampoline: it warps and stretches with gravity.
\nI see time as a fabric as well, except I take that fabric and flatten it, compress it into a single plane. One of the unique aspects of this work is also, if you look at all my pictures, the time vector changes: sometimes I'll go left to right, sometimes front to back, up or down, even diagonally. I am exploring the space-time continuum within a two-dimensional still photograph.
\n[…] I build a photograph based on time. […]
\nI'm compressing the day and night as I saw it, creating a unique harmony between these two very discordant worlds.
\n[…] Time is this extraordinary thing that we never can really wrap our heads around. But in a very unique and special way, I believe these photographs begin to put a face on time. They embody a new metaphysical visual reality. […]
\nI realised that Day to Night is really a new way of seeing.
\n
\n\nI watched over 15 hours all these people not even look at Sacré-Coeur. They were more interested in using it as a backdrop. They would walk up, take a picture, and then walk away. And I found this to be an absolutely extraordinary example, a powerful disconnect between what we think the human experience is versus what the human experience is evolving into. The act of sharing has suddenly become more important than the experience itself.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-09-23T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/09/what-will-happen-to-code/", "url": "https://matthieuoger.com/2019/09/what-will-happen-to-code/", "title": "What Will Happen to Code?", "content_html": "[Near a watering hole in the Serengeti National Park in Tanzania] What I witnessed was unimaginable. Frankly, it was biblical. We saw, for 26 hours, all these competitive species share a single resource called water. The same resource that humanity is supposed to have wars over during the next 50 years. The animals never even grunted at each other. They seem to understand something that we humans don't. That this precious resource called water is something we all have to share.
\n
Pieter Levels in “No Code”:
\n\n\nIn the future writing actual code will be like using a pro DSLR camera, and no code will be like using a smartphone camera. Some pros will keep doing work with DSLRs (and need them), but most basic apps will be built with no code.
\n[…]
\nI think we'll see coding go in two directions:
\n\n
\n- towards simplicity with no code, for 95-99% of apps
\n- towards complexity with custom high-level engineered code, for the 1-5% of apps
\nThe engineers working on (2) will be high paid, in the millions/year, because custom code.
\n
This is my theory as well. I'm pretty confident that in 20, maybe 40 years, nobody will write actual code for most use cases. We will still have craftsmen, that will build low-level libraries, OSes and computing bricks, then integrated by platforms that everybody will use. Gluing, mixing and combining APIs, UIs, sensors and any other tool will be as simple as piping commands in a shell for a developer today.
\nNowadays' coding is too dangerous, brittle, slow and painful to continue like that forever. It's still baffle me that forgetting brackets around a if statement can produce an extremely serious vulnerability issue, that can potentially impact everyone on earth.
As long as we write code like we did 50 years ago, this will continue to be true. We will continue to make the same mistakes, we will continue to create bugs just by calling an API or rendering a few graphical elements on a screen. It's no wonder that the average quality of softwares is so low right now: considering the number of layers you have to take into account, the pace of the industry, the requirements and the variety of environments, it's already impressive that humanity was able to go this far with such a primitive tooling — it's a giant effort and a long struggle to be able to create something of quality in the software virtual world.
\nSurprisingly, and maybe hopefully, programmers are probably the only one that are actually eagerly trying to create the next-generation of tools that will replace them.
\nIt's been a long time that I've formed this opinion in my head, and these are the reasons that I choose to not focus entirely on programming for the last years, but instead on the products at a higher level.
\nSoftware engineers will probably become like blacksmiths (or similar professions): a few are highly valued for the quality of their work, and the dedication to their craft, but the other 99% have vanished or been replaced by low-wage jobs.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-09-08T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/08/art-of-lists/", "url": "https://matthieuoger.com/2019/08/art-of-lists/", "title": "Art of Lists", "content_html": "\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-08-26T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/08/fast/", "url": "https://matthieuoger.com/2019/08/fast/", "title": "Fast", "content_html": "Occasionally we need to write something that must be understood, absorbed, and acted on. The more important it is that readers understand and act, the more time you should spend refining the writing.
\nThere are a lot of things you can do to make an email, blog post, proposal, or process document clearer. For example you can keep it short, make it engaging, or have a colleague refine it before sending it out. These can all help a lot.
\nHowever, if it’s critical to you that your writing is read – especially by busy people – you need to make it skimmable.
\n[…] There is one core approach though, one workhorse of the skimmable document, that is worth mastering: lists. […] I’d like to share one weird trick to quickly writing a clear and useful list: The Bolding Trick.
\n
Craig Mod in “Fast Software, the Best Software”:
\n\n\nI love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.
\nSoftware that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance.
\n[…] Because — it’s not quite as fast. We’re talking milliseconds, but it’s enough that you feel the difference.
\n[…] Still, the slowness feels indicative of unseen rot on the inside of the machine. The slowness is like an off smell. I don’t trust the application as much as I would if it didn’t slow down […]
\nSpeed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk. I want all my craftspeople to stickle.
\n[…] I love software that does this: Software that unbloats over time. This should be the goal of all software. The longer it’s around, the more elegant it should become. Smooth over like a river stone.
\n[…] But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow.
\n[…] It feels — intuitively — that software (beyond core functionality) should aim for speed. Speed as a proxy for efficiency. […]
\nUltimately, to be fast is to be light.
\n
He's talking about software — where it's most perceptible —, but I think this could also be easily applied to physical objects.
\nAs an aparté, but similarly, Craig also wrote this sentence that I like a lot in his latest Roden newsletter:
\n\n\nPart of me wishes there was more of a trend in the startup world to build sustainably small, single-serving, hyper-focused, culturally-impactful businesses.
\n
Related to this topic, John Siracusa in episode #337 of ATP:
\n\n\nThat's what I want. I don't want to be waiting for the computer for things that I shouldn't have to be waiting for the computer for. For small interactive things. That involves, like, it's not saying \"oh yes, eliminate animations because it takes too long\". I just want everything to be interactive… all the time.
\nI want it to be responsive to my input.
\n
This really is the crux of the problem. As soon as you start your actions and you have to stop because the software is not able to follow you, it's over (exhibit A: Jira, or as John's co-host says…).
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-08-01T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/07/book-basecamp/", "url": "https://matthieuoger.com/2019/07/book-basecamp/", "title": "It Doesn't Have to Be Crazy at Work", "content_html": "Random highlights taken from the book “It Doesn't Have to Be Crazy at Work” by Basecamp.
\nPage 176:
\n\n\nLater is where excuses live. Later is where good intentions go to die. Later is a broken back and a bent spirit. Later says “all-nighters are temporary until we’ve got this figured out.” Unlikely. Make the change now.
\n
Page 185:
\n\n\nBeing clear about what demands excellence and what’s perfectly okay just being adequate is a great way to bring a sense of calm into your work. You’ll worry less, you’ll accept more. “That’s fine” is such a wonderfully relaxing way to work most of the time. Save the occasional scrutiny for the differentiating details that truly matter.
\n
Page 182:
\n\n\nWe’ve been practicing disagree and commit since the beginning, but it took Bezos’s letter to name the practice. Now we even use that exact term in our discussions. “I disagree, but let’s commit” is something you’ll hear at Basecamp after heated debates about specific products or strategy decisions.
\nCompanies waste an enormous amount of time and energy trying to convince everyone to agree before moving forward on something. What they’ll often get is reluctant acceptance that masks secret resentment.
\n
Page 252:
\n\n\nJean-Louis Gassée, who used to run Apple France, describes this situation as the choice between two tokens. When you deal with people who have trouble, you can either choose to take the token that says “It’s no big deal” or the token that says “It’s the end of the world.” Whichever token you pick, they’ll take the other.
\n
Page 20:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-07-30T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/07/withhold-the-fun/", "url": "https://matthieuoger.com/2019/07/withhold-the-fun/", "title": "Withhold the Fun", "content_html": "It begins with this idea: your company is a product.
\nYes, the things you make are products (or services), but your company is the thing that makes those things. That’s why your company should be your best product. […] That, like product development, progress is achieved through iteration. If you want to make a product better, you have to keep tweaking, revising, and iterating. The same thing is true with a company.
\n[…]
\nBut when you think of the company as a product, you ask different questions: Do people who work here know how to use the company? Is it simple? Complex? Is it obvious how it works? What’s fast about it? What’s slow about it? Are there bugs? What’s broken that we can fix quickly and what’s going to take a long time?
\nA company is like software. It has to be usable, it has to be useful. And it probably also has bugs, places where the company crashes because of bad organizational design or cultural oversights.
\nWhen you start to think about your company as a product, all sorts of new possibilities for improvement emerge. When you realize the way you work is malleable, you can start molding something new, something better.
\n
John Siracusa, in episode 335 of ATP:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-07-29T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2019/04/a-real-dial/", "url": "https://matthieuoger.com/2019/04/a-real-dial/", "title": "A Real Dial", "content_html": "\"We are trying to win on quality\". And if you try to win on quality in the enterprise, that is not a winning strategy, because, we established before the definition of enterprise software, the people who pay for the software and select it are not the people who use it so your software being more desirable for users means almost nothing in the enterprise.
\nAll that matters is: does it do the thing that I needed to do, does it check all the checkboxes for compliance and blablabla and how much does it cost?
\n
From “A Spectre Retrospective”:
\n\n\nRemember how I talked about the exposure duration dial, and how I really wanted it to feel like a tactile control like the one you have on a camera? The delightful clickiness of it, its precision, the appearance of etched metal… Delicious. How could we possibly translate this to a digital user interface? You’d just be tapping on glass.
\n[…] The only issue was that my big silly thumb would totally obscure the control. […]
\nBut we didn’t have to also emulate the limitations of the physical world along with its wonderful tactile qualities: this is the digital world. We can make tiny phones fly. We can use a machine brain to pick the right settings for you.
\nWe can make the dial expand gracefully as you select an exposure time.
\n
Thus:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2019-04-13T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2018/12/better-meetups-conferences/", "url": "https://matthieuoger.com/2018/12/better-meetups-conferences/", "title": "Better Meetups and Conferences", "content_html": "This is probably my favorite part of the interface. Everything about it feels and looks perfect; Ben’s custom spring physics, my visual design iterations, and Jelmar’s completely custom typeface we use for the numerals. Three people worked hard on this little doodad — and most users probably wouldn’t even notice the work we put into it!
\nI would argue that’s how you know that you’ve made something well.
\nWhen you come across an article set in a superb typeface for reading, some excellent airport signage or a well designed door handle, you don’t think about it or even notice it. If anything you might just notice being happier, or simply not frustrated. That’s how you know a design is great: it disappears.
\n
I was watching this talk by Jessie Char and it reminded me of some thoughts I have each time I attend a meetup or conference.
\nI think we could improve these events with some little tweaks that would make the experience of every attendee better.
\nThere're many other things to do, but these are my main frustrations. For the rest, the talk linked above is excellent! :)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2018-12-13T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2018/12/tools/", "url": "https://matthieuoger.com/2018/12/tools/", "title": "Tools", "content_html": "From “Blood, Sweat and Pixels” (written by Jason Schreier):
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2018-12-05T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2018/11/flank-it/", "url": "https://matthieuoger.com/2018/11/flank-it/", "title": "Flank It", "content_html": "\nThe biggest differentiator between a studio that creates a really high-quality [product] and a studio that doesn't isn't the quality of the team.
\nIt's their dev tools.
\nIf you can take fifty shots on goal, and you're a pretty shitty hockey player, and I can only take three shots on goal and I'm Wayne Gretzky, you're probably going to do better.
\nThat's what tool are. It's how fast can you iterate, how stable are they, how robust are they, how easy it is as a nontechnical artist to move a thing.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2018-11-26T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2018/11/bad-design/", "url": "https://matthieuoger.com/2018/11/bad-design/", "title": "The Cost of Bad Design and the “Ghetto of Inattention”", "content_html": "[This] one is pretty goddamn important: Don’t try to beat a network by making a clone with improvements. It ain’t gonna work. There is too much gravitational inertia in the original network; nobody is incentivized to leave it.
\nThere are some approaches that will work […]. Both approaches require you to get into an entirely different market and build a network there. You can’t beat a strong network head-on, but you can flank it.
\n
From the “Wireframe” podcast, “Good Design is Human”:
\n\n\nKHOI: […] It’s the idea that design should make tech comfortable for people. It should put people at ease. So you have all these little cues that make people feel like they can explore the tech, they don’t have to worry about being caught in a trap or inadvertently triggering a nuclear meltdown.
\nAMY: But while human-centered design had permeated the world of consumer technology, not every industry has been as quick to adopt it.
\n[…]
\nAMY: In January 2018, an employee at The Hawaii Emergency Management Agency mistakenly issued a state-wide alert that went straight to residents’ cell phones. “Ballistic Missile Threat inbound to Hawaii,” it read. “Seek immediate Shelter. This is not a drill.”
\n[…] This was supposed to be a safety drill. But the guy at the controls clicked on the wrong link. And you kind of can’t blame him… when you see the screen that he was looking at.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2018-11-14T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2018/10/give-it-five-minutes/", "url": "https://matthieuoger.com/2018/10/give-it-five-minutes/", "title": "“Give It Five Minutes”", "content_html": "\nKHOI: I mean, on the one hand, technology that consumers interact with has gotten so much better. We don’t have manuals anymore. Everything is much, much more intuitive. And so, design has really come a long way in that respect. But there’s this whole other sector of technology – the stuff that you and I don’t get to interact with everyday. The stuff that– power plants or emergency centers. That stuff still is pretty rough still.
\nCLIFF: The stuff that really needs to be redesigned is not apps and things like that. It’s the gnarly ugly enterprise software out there that sort of has escaped real scrutiny right? So, let’s say some piece of software for managing a trucking fleet.
\nAMY: Too many of these kinds of tools still aren’t streamlined and friendly and easy-to-use the way our smart phones and laptops are. They have not yet, in other words, received the benefit of human-centered design.
\nCLIFF: All these things actually, they exist almost in this kind of like “ghetto of inattention”. The greatest opportunities are within those things, this like gnarly machinery of everyday commerce that really powers the world we live in, but that has escaped notice.
\n
\n\n[Richard Saul Wurman] said “Man, give it five minutes.” I asked him what he meant by that? He said, it’s fine to disagree, it’s fine to push back, it’s great to have strong opinions and beliefs, but give my ideas some time to set in before you’re sure you want to argue against them. “Five minutes” represented “think”, not react. He was totally right.
\n[…]
\n[He] has spent his career thinking about these problems. He’s given it 30 years. And I gave it just a few minutes. Now, certainly he can be wrong and I could be right, but it’s better to think deeply about something first before being so certain you’re right.
\n
This comes to my mind every time I face new ideas, laws, structures, products, redesigns, or just a change in my life.
\nWhen we talk about politics, for example, it's really easy to dismiss what someone is doing and say \"it's so stupid and I would do this instead of that, of course!\". Without understanding the big picture, or the keys behind a problem, yeah, for sure we would do differently. This is not a justification for world destruction or horrible legislations, but a mental framework to acquire knowledge about why it's like that and how it could be really improved.
\nIt's hard, and we all fell for it, but each time I try to understand the motivation or the why behind something I would push against, it always makes more sense, whether I liked it or not. Then, I get a better grasp on the problem. And sometimes, it can even change my mind.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2018-10-31T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2018/10/unity-iphone-x-home-indicator/", "url": "https://matthieuoger.com/2018/10/unity-iphone-x-home-indicator/", "title": "Unity and iPhone X's Home Indicator", "content_html": "\n\nCheck the
\nBottomoption for \"Defer system gestures on edges\" in theEdit → Project Settings → Playermenu of Unity to make the iPhone X's home indicator less visible and obtrusive in your project.Don't use \"Hide home button on iPhone X\". This is not what you want for a game.
\n
We are porting Steredenn: Binary Stars to iOS right now, and with the port comes the support for the iPhone X new form factor (yes, it's a bit late, I know…).
\nWhen trying the game on an iPhone X, I was not happy with the way the home indicator was always visible, distracting the user while playing Steredenn. I looked at other games and saw that it was possible to change its behavior.
\nHowever, it was not really clear how to do that with Unity, so I hope this will help others.
\nSince the iPhone X, the mechanism to go back to the home screen has changed on iOS. You have to swipe from the bottom of the screen, which puts the app back inside its icon.
\nBy default, at the bottom (where the chin was), the home indicator is always visible in an app. It's the black bar you can see on this screenshot:
\n![\"Home](\"/images/posts/2018-10-18/home-indicator.jpg\")
For the moment, it's a permanent indicator if the app does not specify a different behavior.1
\nSee what it does in action:
\nIt's a thoughtful UI that follows the finger precisely. With the haptic feedback, it's actually very nice to play with.
\nHowever, this (default) behavior is not great for games. It's too bright and it hides a small portion of the bottom part of the screen. Which can be confusing in games like Steredenn, where many things are displayed at the same time.
\n![\"Home](\"/images/posts/2018-10-18/steredenn.jpg\")
Fortunately, Unity (well, technically, it's iOS) provides 2 ways to change the home indicator. Obviously with Unity, the correct one is not the one you would expect.
\nYou can find these settings by following this procedure:
\nEdit → Project Settings → Player.![\"Open](\"/images/posts/2018-10-18/unity-01.jpg\")
![\"Find](\"/images/posts/2018-10-18/unity-02.jpg\")
![\""Hide](\"/images/posts/2018-10-18/unity-03.jpg\")
\"Hide home button on iPhone X\", the one that looks like what we want, is, of course, the wrong one.
\nThis setting hides the home indicator after a certain inactivity delay. If the user taps on the screen, the home indicator appears again in its full bright glory. In a game, where you will tap all the time, it's the same as showing the indicator permanently.
\nNote that this setting can be useful sometimes. For example, if you are doing a video player, or a game that does not require user inputs often, this is what you want. I think there is ways to toggle this behavior when needed.
\nThis is what YouTube does, for example (it's hard to see cos' the home indicator is black here, but look at the bottom):
\nAs you have guessed now, this is the setting we need.
\nIt does two things:
\nThe \"bottom\" checkbox is enough if you only want to change the home indicator behavior. The other checkboxes can be used for Control Center and other gestures on iPad, I think.
\nThis is what Alto's Adventure does, as well as Steredenn:
\nI think it will be hidden or removed in a future version of iOS when the behavior will be accepted by most people. Currently, it's a nice affordance and the space it takes is necessary while the users are getting used to it.
\n↩\nCyrus Farivar at Ars Technica:
\n\n\nBut [Glory To Rome] (GTR) felt different. First, I noticed the packaging. Unlike the high-quality large-format cardboard boxes with soft colors and thoughtful art, GTR came in a compact, cheap, plastic tub that wasn’t much bigger than a large paperback book. Second, and more jarring, was the game's art. It had a bright color palette and cartoonish characters that seemed like they belonged in a children’s clip art computer game.
\n[He] started unpacking the game and patiently explaining the rules. What immediately struck me was the mechanic allowing the player to choose what type any given card would be—one of a few choices that would automatically exclude the others. GTR appeared to be full of intrigue and strategy, and there were multiple ways to win. […]
\nIn less than a decade, how could a game whose ranking still remains relatively high (150) on Board Game Geek — just a few places above Magic: The Gathering and a few places lower than Carcassonne — have totally disappeared? What happened? […]
\n\"It’s one of those games, you just recognize the genius of the design of it,\" Lozito told Ars. \"This is one of the quintessential big games in a small box. Every time you sit down to play it it plays differently, the cards are all crazy. I looked at the game and I have no idea how his brain could come up with such a complex game out of 125 cards or whatever.\" […]
\nAs GTR continued to gather critical and cult-classic steam, word started getting back to [co-creator Carter] that one of the game’s primary problems was its awful production—those nausea-inducing colors and a cheap plastic box. […]
\n[After the Kickstarter's success], this should have been the moment that Carter seized game-design glory. With a successful production, he could have taken the game from indie cult favorite to something much bigger. But according to Rao, this influx of cash instead represented the beginning of the end.
\n
Here's a description from Ed Carter, one of the \"co-creators\":
\n\n\nEarly on, Glory To Rome was often called \"San Juan on Steroids,\" but it would probably be more accurate to call it \"San Juan meets Magic The Gathering.\" There are 40 different cards in Glory To Rome and each one has a unique ability. Only four of them are sensible \"Improve your X by Y\" abilities—the rest are ridiculous, convoluted powers like \"Incomplete MARBLE structures provide function.\" That generates 760 different two-card combinations and many thousands of three-card ones. I've played hundreds of games of GTR over the years so I've thought about a lot of these combinations, but certainly not all of them.
\nAlso, while most games are balanced using a stable equilibrium with the aim that no card should be so overpowering that it breaks the game, Glory To Rome is balanced using astable equilibrium—our aim was that in the right combinations, virtually every card would be able to contribute to a runaway victory.
\n
I was never aware that the game was unavailable. I got a copy of the French version (by Filosofia) a few years ago when it was in store almost anywhere in France, in a reprinted and decent version, so this story is all news to me. It's funny to think that the game was \"everywhere\" here, but unavailable in its home-country.
\nIt's a shame though, since the game is really, really great.
\nSide note: the work by Heiko Günther is beautiful too. I think that the French version is clearer in an actual game, but wow this is pretty.
\nThis article makes me think that many boardgames disappear each year, going unnoticed and forgotten forever.
\nI wrote about Quantum before, one of my favorite boardgames, which is out of stock too. I looked for a new copy a few months ago, and to my surprise, wasn't able to find one. I looked today, and the game is not even listed on most sites anymore.
\nEach year1, an increasing number of new games is released, and each year, an even bigger number is retired. The disturbing thing, however, is that most of these games are, actually, great games.
\nOnly a small and highly-successful portion of all the boardgames will be kept forever (Catan, Race for the Galaxy, Carcassonne, Monopoly, 7 Wonders, etc.). Are those the very best of the best? Or just the most successful ones?
\nLike videogames, the number of boardgames produced a year keeps getting bigger. I don't have the numbers, but I've read that the production of the last few years alone might be higher than the whole combined number of games created a few decades before.
\n↩\nIt's been a long time since my last post (more than two years, in fact). And the reason is absurd.
\ntl;dr: I have redesigned Solar Sailer, making the home page the most important one and refocusing this site as a way to find me on Internet. The blog is relegated to a secondary part of the website. I still plan to publish articles, but the focus of Solar Sailer is to quickly know who I am, what I've done and where you can find me.
\nThe rest is a bonus. However, I'm still planning to expand this website in new ways — adding a portfolio and a resume, most notably.
\n ![\"New](\"/images/posts/2018-07-20-reboot.jpg\")
If you want to read more about why it took so long, continue. Otherwise, you know everything. 😉
\nI was using Jekyll to generate this blog and hosting it with GitHub Pages (Jekyll is maintained by GitHub, so the workflow to publish a Jekyll site on GitHub is dead simple if you accept their dependencies and constraints). Then, one day, GitHub said that they were deprecating the Markdown engine that I was using, affecting a few posts I wrote.
\nI wanted to redesign this site for a long time, so instead of just updating the posts, I decided to rewrite the whole blog (like every developer do each time they have a small change to do — it's our curse).
\nI experimented. I designed 6 or 8 layouts. I was never happy, and I never gave me the time to finish it properly. When I started to implement a new design, I let it wither for a few months. And when I came back, I just ditched it all. Again. And again. And again.
\nI moved the blog to Hugo. Then I came back to Jekyll once more. I modernized everything. Then I was fed up with Jekyll again, so I tried Gatsby. And I did other things, abandoning the redesign once again. Meanwhile, and even if I had dozens of drafts, I couldn't update the old blog with new articles. So it languished there, in its infamous uglyness (something I was not proud of, calling myself a designer).
\nAnd finally, I retried Gatsby recently and completed a new design. It's not perfect. It's not well tested on older browsers. But it works, in a good enough way for me — I have already spent too much time on it.
\nI've also cut the dependency I had on GitHub Pages. I'm still using GitHub to host this website, but the workflow is separated and I'm free to use what I want.
\nIt's time to ship.
\nMore than just a simple redesign, I wanted to reboot the site to add a portfolio, a resume, a documentation·codex·tutorials, as well as a photo and automation sections. Of course, if I wanted to do it all, I would never have finished anything, so I just focused on a simple redesign at the time being, keeping in mind that the site would be expanded later.
\nThe goal, in the end, is to do all that — if I'm motivated enough. A good start would be to publish new articles with a regular schedule.
\nAnother thing that was ticking for this website was the \"deprecation\" of HTTP by Chrome in an upcoming update. By deprecation, I mean that Chrome will show an \"Unsecure\" flag on non-HTTPS websites. HTTP will always work, but it will be relegated to a legacy protocol that nobody should continue to use.
\nI was in a hurry to complete this reboot before this update. I soft-launched the new site a few weeks ago, and tweaked it since. And now it's official.
\nTo be a little bit exhaustive:
\nI'm so exhausted by this whole process and that's mainly why I'm so long to end this blog post. 😇
\nI hope you'll like it.
\nI've renamed the site to simply \"Matthieu Oger\". The \"brand\" I was trying to create with the \"Solar Sailer\" name was not working at all. It's better to just drop it and use my name as of now. If you encounter a broken link somewhere, please contact me.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2018-07-20T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2016/04/dwarf-fortress-systems/", "url": "https://matthieuoger.com/2016/04/dwarf-fortress-systems/", "title": "Cats, Taverns and Cleaning Systems", "content_html": "\n\n\nIt’s funny how I have popular bugs, right? You shouldn’t have popular bugs. […] I added taverns to fortress mode, so the dwarves will go to a proper establishment, get mugs, and make orders, and they’ll drink in the mug. And, you know, things happen, mugs get spilled, there’s some alcohol on the ground.
\nNow, the cats would walk into the taverns, right, and because of the old blood footprint code from, like, eight years ago or something, they would get alcohol on their feet. It was originally so people could pad blood around, but now any liquid, right, so they get alcohol on their feet. And then I wanted to add cleaning stuff so when people were bathing, or I even made eyelids work for no reason, because I do random things sometimes. So cats will lick and clean themselves, and on a lark, when I made them clean themselves I’m like, ‘Well, it’s a cat. When you do lick cleaning, you actually ingest the thing that you’re cleaning off, right? They make hairballs, so they must swallow something, right?' And so the cats, when they cleaned the alcohol off their feet, they all got drunk. Because they were drinking.
\nBut the numbers were off on that. I had never thought about, you know, activating inebriation syndromes back when I was adding the cleaning stuff. I was just like, ‘Well, they ingest it and they get a full dose,’ but a full dose is a whole mug of alcohol for a cat-sized creature, and it does all the blood alcohol size-based calculations, so the cats would get sick and vomit all over the tavern.
\nThe original bug report is, ‘There’s cat vomit all over my tavern, and there’s a few dead cats,’ or whatever, and they’re like, ‘Why? This is broken.’
\nPeople helped me with this. We were all looking and figuring out, ‘What the heck is going on here?’, and that was the chain of events. It’s like doing the detective work to figure out that entire chain of events is what happened. You can see how adding just a tavern that gave the opportunity for spilling alcohol, which was really uncommon before, now all the spilled alcohol starts to, form in one location where something could start to happen. You activate bugs and little parts of code from eight, six years ago where you just didn’t balance the numbers because it didn’t matter. […]
\nPC Gamer: So the cats’ inebriation system was just based on any organism would have the potential to get drunk.
\nYeah, right now it’s any creature that has blood, and that includes, like, an octopus. I don’t know if an octopus can get drunk or not.
\n
The way the different systems are all interacting together is so fascinating. Especially when the outcome becomes something like this. :)
\n\n\nI don’t even use version control. If you don’t know what that is then you’re not gonna yell at me. If you even know what version control is you’re gonna be like, ‘You don’t use version control? You don’t use source control? What is wrong with you? How can you even work?’
\n
I'm still baffled to know that many game developers (or other developers) work without version control. It seems so dangerous, but… well.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2016-04-01T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2016/03/delight/", "url": "https://matthieuoger.com/2016/03/delight/", "title": "Delight", "content_html": "Craig Mod in his beautiful essay about the Leica Q:
\n\n\nAnd what is delight? For me, delight is born from a tool’s intuitiveness. Things just working without much thought or fiddling. Delight is a simple menu system you almost never have to use. Delight is a well-balanced weight on the shoulder, in the hand. Delight is the just-right tension on the aperture ring between stops. Delight is a single battery lasting all day. Delight is being able to knock out a 10,000 iso image and know it'll be usable. Delight is extracting gorgeous details from the cloak of shadows. Delight is firing off a number of shots without having to wait for the buffer to catch up. Delight is constraints, joyfully embraced.
\n
Bonus:
\n\n\nIt should not exist. It is one of those unicorn-like consumer products that so nails nearly every aspect of its being — from industrial to software design, from interface to output — that you can’t help but wonder how it clawed its way from the R&D lab. Out of the meetings. Away from the committees. How did it manage to maintain such clarity in its point of view?
\n
And:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2016-03-19T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2016/03/java/", "url": "https://matthieuoger.com/2016/03/java/", "title": "Why Do Many Software Engineers Hate Java?", "content_html": "\nThe Q — like most recent Leicas — is engraved with the softly geometric, proprietary LG 1050 typeface. It feels so, totally, completely at home, stamped into the camera body in all caps. It's highly legible and precisely designed. Minimal, functional, but with a bit of quirky character. Like the Q itself. This is the perfect camera typeface used in the perfect way. Mic dropped. Case closed.
\n
\n\n\nFirst, let's cover the technical issues. It's verbose, combines the worst of both worlds between static and dynamic typing by having a hobbled but extremely clunky type system, and mandates running on a virtual machine (VM) that has a macroscopic startup time (not an issue for long-running servers, but painful for command-line applications). […]
\nThe VM itself has a lot to recommend it. It offers concurrency and garbage collection at a level of quality that, until recently, wasn't found anywhere else. […] Much important software in the early 2000s was written in Java because, at the time, it was the best choice, even taking the mediocrity of the language itself into account. It had Unicode (albeit, UTF-16) from the start and a strong concurrency story, and it was a notch above C++ in terms of user experience. […]
\nIf you put Java on a technical trial, it doesn't do so bad. The language sucks, the platform is pretty good for most purposes. I do hate the dominant interpretation of \"object-oriented programming\" with a passion, because it objectively sucks. […]
\nSo let's talk about the political and cultural issues. First, the dominant Java culture is one of mediocrity and bad taste, with MetaModelVibratorVisitorFactory classes dominating. I've heard a number of experts on \"the Java issue\" argue that Java's biggest problem is the community, and that comes directly from the fact that good programmers don't want to deal with the bastardization of OOP that has entrenched itself in mainstream corporate development. You have a lot of people who trained up as \"Java programmers\", haven't seen a command line ever, and have no clue how the computer actually works. Most of them have never actually written a program; they just write classes and some Senior Chief Architect (who makes $246,001 per year and hasn't written a line of code since the 1990s) figures out how to stitch them together, and then tells some other clueless junior how to implement the glue in the gutshot hope that one will actually have the talent to make an actual working program out of the mess.
\nThis isn't inherent to the JVM, because Clojure (currently hosted on the JVM, although its endgame seems to be language-agnosticism) has a radically different (and better) community. Scala's community is more mixed, but the top Scala engineers (the ones making tools like Spark and Kestrel) are really fucking good.
\n[…]
\nSo, the short answer is: it's mostly not about the underlying platform (which is generally of high quality) and its only partly about the language (which is mediocre but can't be blamed directly for community problems). It goes a lot deeper than that, and not all of it is Java's fault. However, Java takes its share of the blame for its clear favoritism toward large programs (technically, established by its long startup time) and by its support of a very ugly (and counterproductive) variety of object-oriented programming.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2016-03-17T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2016/03/virtual-reality/", "url": "https://matthieuoger.com/2016/03/virtual-reality/", "title": "VR Is Not The Future", "content_html": "\n This is a prediction. I may (must?) be completely wrong—after all, I hold an unpopular opinion and many tech companies seem to think otherwise. We'll see. 🤷\nI’ve read the popular answers and will claim no contest to a majority of the complaints I found. […] However, here’s why I love it. […]
\nIn the Android world, developers use Java because they have to. However, much creativity has sprung from that limitation. People have written many excellent OS libraries in Java for Android. The platform continues to be a hotbed of Java activity which developers contribute to from all over the world. […]
\nAndroid’s open nature, wide distribution, and powerful support from Google are almost enough to make Java hip again. […] Sure, some may argue that other runtimes and languages can enable the same capabilities of the device, but for whatever reason, Android chose Java.
\nUntil Google changes its mind, Java will remain relevant and the source of fascinating developments in the software community as long as Android remains popular.
\n
Virtual Reality (or VR) is a fantasy that many geeks love. It's in books, in movies, in games. In our collective mind, virtual reality is like flying cars: it's a dream that we always envisioned for our future as an high tech society.
\nWell, we all remember that we didn't get flying cars for the new millenium.
\nIncredible technologies portrayed in science-fiction books or movies are generally not really that relevant in reality. Or they are so hard to build that we can't even fathom to create them now. In our history, the way our society evolved was often very different to how we imagined it in our fictions. When you confront with the reality, many dreams are just what they are: dreams. I would need to dig up some sociology courses that I had—but I remember that this is a recurrent theme in our evolution.
\nFor VR, it's a bit different: we (almost) have the technology. However, I do think that it's just a fad. A fad that excites many marketers or entrepreneurs. Real-world applications are so narrow.
\nVR is a cool demo. VR is impressive. Even with our primitive VR technologies, it's still incredible to try.1
\nVR is also making people sick—yes, many people suffer from motion sickness.
\nVR is pretty boring for games, its main application right now. Yes, the immersion is better. Nop, the controls are worse. You can't move in a game without hitting a wall. You can't use your hands without complex gloves or other utensils. The possibility are not that huge: okay, it might be great for some first-person games where you don't move. But that's just a small subset of all the games we can create.
\nVR is ugly. VR is cumbersome. VR is like Google Glass (remember that?) in so many ways.
\nIf you're at home, it might be fine, although that wearing another thing on your head is not that comfy. I already wear glasses, I really don't want to add something more on my head, I assure you. Especially if it means that I might hit a wall someway.2
\nOutside? At work? We are going to need many years to be okay with that.
\nThe day we'll be able to have VR headsets the size of a regular pair of glasses is far. We might be already destroying our eyes by viewing screens all day—I can't wait to wear VR headsets a few centimeters from my retinas all the time!
\nVR is not completely useless. There's some fields where virtual reality might be useful. Want to visit a new flat in a town far far away? You're a future surgeon and you need to practice during your school years? There's a myriad of applications outside of gaming and home uses.
\nUnfortunately, right now, people imagine that VR will be used to handle and manipulate softwares, computers or playing games. That's absurd.
\n\nUsing VR to work on scenes in the Unity Editor: @timoni's demo on-stage at #GDC16: https://t.co/tbUmVAemBU #unity3d pic.twitter.com/T1EH8MsLWb
— Ben Pitt (@robotduck) March 15, 2016
Seriously? Who would do that? What the point? Who in their right mind thought it was a good idea!?
\nWhen I say that VR is not the future, I don't mean that VR will disappear completely. But we need to take a step back and really think about it. We need to stop to try to put VR everywhere—it's just a waste of time.
\nThe only application that will make VR a general use product might be porn. Honestly, except for that, I don't see a future where VR is ubiquitous. That just doesn't make any sense.
\nVirtual reality is a fad. And right now, journalists and tech companies are all buzzing and craving for that. When the first officially released headsets will be available, I expect a massive flop. As soon as the novelty wears off, people will just forget it. Because outside of some narrow use cases, it's just not practical or invisible enough.
\n\nTim Urban about rehearsing for his TED Talk:
\n\n\nI’ve mentioned before that we all have this problem where we’re weirdly obsessed with what other people think of us, so it makes sense that public speaking should be our collective phobia.
\nBut then we also live in a world where public speaking can happen to any of us at any time. […]
\n\"Hey TED Staff,
\nI've decided to do my talk on procrastination. It's the thing I'm best at.
\nBest,
\nNovember Tim\"
\n[…]
\n[My rehearsal] was three days before my talk—and it was pretty rough, confirming to me and everyone present that I was officially not a fraud when it came to my topic. The irony of a guy rehearsing his TED Talk about how he’s a bad procrastinator, and being clearly underprepared while doing so, was not lost on anyone.
\n
UPDATE: and the talk is up on TED. No surprise: it's great.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2016-03-15T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2016/02/invention-center/", "url": "https://matthieuoger.com/2016/02/invention-center/", "title": "Invention Centers", "content_html": "\n\n\nInvention centers are 20 to 40 people doing odd things. Innovation is the process of taking something that’s already been invented and packaging it nicer.
\nProblem-finding is about how to get something out of almost nothing in some new area. You're by definition not doing something incremental. There’s a lot of playful stuff going on. The probability of a good idea is pretty low. Most of the ideation that happens [in an invention center] are things that get rejected, which is normal in this line of work. Very few people understand that.
\n
Later:
\n\n\nThe shortest lived group at Xerox PARC was \"Office of the Future,\" because Xerox executives would not leave them alone.
\nI chose the most innocuous name for my own group, the Learning Research Group. Nobody knew what it meant, so they left us alone to invent-object oriented programming and the GUI.
\n
So weird that something like CDG is backed by SAP.
\n(via Avdi Grimm)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2016-02-16T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/10/sad-state-web-deployment/", "url": "https://matthieuoger.com/2015/10/sad-state-web-deployment/", "title": "The Sad State of Web App Deployment", "content_html": "\n\n\nWe’ve been doing this for 20 years. We should have this by now. It should work, it should be pluggable and agnostic, and it should do everything right. […]
\nInstead, we stack layer after layer of additional convoluted crap on top of what we’ve already got because we don’t know how to fix it. Instead, we flit constantly from Thin to Mongrel to Passenger to Heroku to Bitnami to Docker to whatever new way to deploy trivial apps came out yesterday. Instead, we obsess over adding better Sass integration to our frameworks.
\nAnd I’m really not picking on Ruby, or Rails, or this particular app. I hate deploying my own web software, because there are so many parts all over the system that only barely know about each other, but if any of them fail then the whole shebang stops working.
\n
See also: Something Slightly Less Terrible.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-10-13T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/09/semicolon-comma-programming/", "url": "https://matthieuoger.com/2015/09/semicolon-comma-programming/", "title": "Compilation by a Thousand Semicolons and Commas", "content_html": "Something I like in most modern programming languages is that they tend to ditch semicolons completely.
\nSemicolons are a nuisance, a waste of time, a source of (easily fixable) errors, ugly and unnecessary.
\nCompilers can easily work without them. Keeping them in old languages is, most of the time, simply a question of backward-compatibility.
\nAnd that's fine, after all. In modern languages though, this is something that must be avoided. It's wrong and useless.
\nConsider this snippet of Swift:
\nvar greeting = \"Hello!\"\n\nif let name = optionalName {\n greeting = \"Hello, \\(name)\"\n}No semicolon. Great. Now, consider a similar snippet of Go:
\nfunc sqrt(x float64) string {\n\tif x < 0 {\n\t\treturn sqrt(-x) + \"i\"\n\t}\n\n\treturn fmt.Sprint(math.Sqrt(x))\n}It's pretty nice, isn't it?
\nGo does use semicolons in its grammar. However, it's the lexer's role to add them, not the developer. Let the machines do the shit work.
\nHere's the extract from Effective Go:
\n\n\nLike C, Go's formal grammar uses semicolons to terminate statements, but unlike in C, those semicolons do not appear in the source. Instead the lexer uses a simple rule to insert semicolons automatically as it scans, so the input text is mostly free of them.
\n
And unlike in an extremely popular language, Go imposes some formatting rules to its programmers and nobody has a problem with ASI.
\nHowever, there's still one perfectly valid case where semicolons are not optional:
\nif v := math.Pow(x, n); v < limit {\n\treturn v\n}Between math.Pow(x, n) and v < limit, you will find a semicolon. Because the two statements are on the same line, the compiler needs a semicolon to know where to end a statement and start the next one.
Basically, the rule is simple:
\nThat's the basic consensus in new languages.
\nSo, here's my question: why don't we do the same thing with commas?!
\nLet's look at the following snippet of Swift:
\nvar test = [\"a\", \"b\", \"c\"]As you can see, each value of the array is separated by a comma. Same rule as the semicolons: if you are on the same line, use a separator. In this case, it's a comma instead of the semicolon because the semantic is different. Fine.
\nNow, let's look at the same snippet with a multi-lines notation — this example might seem contrived, but this kind of notation is clearer when the values are more complex and/or numerous:
\nvar example = [\n \"a\",\n \"b\",\n \"c\"\n]Wait. What. It's exactly like in the one-line declaration just above. Which is not surprising, because almost any language will do that.
\nThat's inconsistent though. For semicolons, we omit them when there's a newline, but here, for a comma, we do not.
\nThe correct syntax should be:
\nvar test = [\n \"a\"\n \"b\"\n \"c\"\n]Simpler, prettier. And it gives a few bonuses beyond the cosmetic aspect:
\nIt's more practical for versioning tool's diffs:
\n![\"Diff\"](\"/images/posts/2015-09-27-diff.png\")
I would apply the same rule to functions definition, maps or anything which needs commas, like I wrote in this example:
\n// One-line, comma.\nfunc test(x: Int, y: Int) {}\n\n// Or:\n\n// Multi-lines, no comma.\nfunc test(\n x: Int\n y: Int\n) {\n\n}In Go, those notations are not frequent because the formatting rules are stricter. However, in a struct definition, you must write this:
\ntype Point struct {\n X int,\n Y int,\n}(Note the trailing comma on the last line.)
\nIt's better than what Swift does (at least, diffs are not impacted and you don't have to think to add or remove a comma — you just have to).
\nBut why did they choose to keep the commas? No comma at all would have been way better AND coherent with the semicolon rule.
\nAnd you know what is even more inconsistent? This, which is perfectly valid Go code:
\nvar (\n x = 1\n y = 2\n z = 3\n)Yep, this time, there is nothing at all.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-09-27T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/09/what-makes-indie-hit/", "url": "https://matthieuoger.com/2015/09/what-makes-indie-hit/", "title": "What Makes an Indie Hit?", "content_html": "“What Makes an Indie Hit?: How to Choose the Right Design” by Ryan Clark (of Crypt of the NecroDancer) is an interesting read:
\n\n\nIn this industry it's difficult to go far without learning from others. But from whom should we learn? I think it is wisest to study developers who have been repeatedly successful. Each time a developer creates another successful game, it becomes less and less likely that their repeated successes have been due to luck. Only a minuscule fraction of indie games break even, so what are the odds of developers like Jamie Cheng, Edmund McMillen, and Cliff Harris stringing together a number of successful games? The odds are low. There must be something other than luck at work! So perhaps these folks (and many others like them!) are the ones you should be studying and listening to.
\n
I generally agree with the article (read it!), but there is one point that bothers me.
\n\n\nIf you want people to remember your game, to talk about your game, to write articles about your game, etc, it needs to have a hook. Preferably multiple hooks!
\n
Ok. This is spot on. However, and while I think that innovative games are important and crucial to explore original ideas and designs, not every game can be a new experience.
\nWe need fun and excellent games in existing genres. Having brilliant roguelike, RTS, shmup, point & click, you name it… is equally important. And in this case, how do you hook people?
\nWhat we wanted to do with Steredenn (my game) is an excellent shmup-roguelike. We don't want to reinvent a genre or to experiment. We just want to make a great, fun, polished and addictive game. That's all. There's a market for a game like that — but we struggle to stand out of the crowd (and we tried many things like articles, arcade cabinet, tutorials, shows, devblog, contacts, press, etc.).
\nIf we had followed the \"hooks rule\", we would never have made Steredenn.1 But I truly think there's a place and an audience for this kind of games.
\ntl;dr: Should every game have a hook, a \"gimmick\", a unique twist? I don't think so.
\nTo be fair, I want to discuss of something else:
\n\n\nIf you are unsure of the strength of your game's hooks, test them! With NecroDancer we did this by putting out a very early teaser trailer, and by demoing at PAX.
\n
\"Demoing at PAX\" is not something that everyone can afford. I'm all for the \"try your game in real as soon as possible\" mantra, but going to a big show is out of scope for almost any indie. It costs a lot just to present your game — and I don't even count the transportation, the food and hostels.
\nWhen we went to Rezzed, we spent about £2000. It was close to us so the travel was very cheap.2 Rezzed is also no PAX or Gamescon.
\nWith our finances, we can afford one or two big exhibitions a year, if we are lucky. I don't think we are the only one in this position. I even think that we are in a privileged situation compared to many indies.
\nI don't want to fool myself: big shows are very important to get feedbacks, coverage and press. And this is something that many indies can't do at all. Languages, geography, finances — this is not an easy problem.
\nAnd as Ryan tells us a little bit later:
\n\n\nIt is common these days for devs to downplay the importance of festivals, awards, and even of press. I disagree. Sure, accolades and reviews themselves may not drive mountains of sales, but most people need to hear about your game from numerous sources before they'll actually watch a trailer or buy the game.
\n
Exactly. :)
\nTo Ryan's credit, he's also ending his article with:
\n\n\nI know how difficult it is to succeed as a new indie dev, and I am aware of the advantages that I have due to experience, connections, and reputation.
\n
Thanks for the tips, anyways!
\nFascinating post-mortem of Quantum, by its designer, Eric Zimmerman:
\n\n\nQuantum is a strategy game for two through four players that incorporates elements of tactics, resource management, and empire building. Players each begin the game with a small fleet of three starships on a customizable map built of modular tiles. Your goal is to expand by building Quantum Cubes on planets, along the way growing your fleet and evolving its abilities. […]
\nAnother element that opened up the possibilities of the game during this early prototyping period was the addition of special power cards. While I was working on it, I remember seeing a talk at the Game Developers Conference by Rob Pardo, one of the lead designers of World of Warcraft. According to Rob, one of the philosophies at his company Blizzard was to make the player feel overpowered. According to Rob, special abilities and power-ups should feel mighty and spectacular, rather than just being some kind of incremental stat improvement.
\nAs I started adding the advance cards to the game, I tried to have them embody this approach, especially when it came to the permanent card powers. My goal was that every card should feel incredibly powerful – a potential game winner in the right situation. I loved seeing my playtesters' faces grow greedy as they read the cards, astonished at how good the powers seemed to be.
\nThe challenge of powerful cards, of course, is balancing them. […]
\nDesigning the right mix of cards came down to good old-fashioned balancing and testing. There are a number of heuristics I tried to use in designing the cards to be balanced. For example, no card simply gives players an extra fourth action each turn; instead, some cards give you an extra action, but that action is limited, such as a free move that is only one space. There are also cards that do give you a completely open-ended extra action, but only if certain conditions are met, such as if you have more ships on the map than any other player. […]
\nIt seemed hopeless; I had designed a game with a combat system that no one wanted to use! The solution to this problem was to directly link combat to winning the game. […]
\nOne strong focus of our work was the language of Quantum: the terms in the rules, the names of the cards and units, and the other words we used in the game. In early prototypes, the titles of the advance cards were more technological: \"Ferocious\", the card that gives you a combat bonus, was originally called \"Armor\", while \"Energetic\", which gives you a movement bonus, was titled \"Propulsion\".
\nThe names of the card were clear, but they felt generic. Thinking about how to emphasize the player-as-commander, I changed the names from nouns to adjectives. Rather than describing the player's fleet, the cards now described the player. Instead of \"Fuel\", \"Evasion\", and \"Engineering\", the cards now had names like \"Brilliant\", \"Cruel\", and \"Stubborn\".
\n
Quantum is one of the best boardgames I recently played. It was unavailable for a year but I finally got my hand on the re-edition. The post-mortem shows all the history behind the game and how some concepts were found and implemented.
\nThe game is really fast, complex and deep. There's a bit of chance in the game through the roll of the dices (obviously), but I don't think it matters that much in the end. Your decisions are way more important than your luck.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-09-15T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/09/rule-of-two/", "url": "https://matthieuoger.com/2015/09/rule-of-two/", "title": "The Rule of Two", "content_html": "\n\n\nThe rule of two is that two is one — and one is none. This is applicable to so many things in your life. As a starting point, I often like to think of the rule of two with things that you have around the house. So, for example, if you have one roll of toilet paper, you really don't have any toilet paper. Because when that one runs out, you're in trouble. So you really need two rolls of toilet paper at all time. It's a redundancy rule, basically. It's where this comes from. […]
\nThis is one of my little pieces of advice for trying to run a life very smoothly. It's that, everything that you can possibly have two of, you should have it. Two shampoo bottles, two bottles of vitamins, two boxes of cereal, two cartons of eggs. You want duplicates of everything. And then, when you're down to one of those things, that's the sign that you need to buy the next one. In this way, you are never out, you're never out of anything. […]
\nIt's applicable to everything in your whole life, everything that's important.
\n
This is so spot on. I try to function like that, but I never put words onto this behavior. Here it is.
\nGrey continues:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-09-09T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/08/dead-or-finished-libraries/", "url": "https://matthieuoger.com/2015/08/dead-or-finished-libraries/", "title": "Dead or Finished Libraries?", "content_html": "Think this way with computer files: you have only one copy of that file, guess what? You have no copy of this file. I even think it's applicable to work. If you have one source of income, in many ways, it's like you have no source of income. Because if something happens with your main job, you are in lots and lots of trouble. One source of income, no source of income.
\n
Twelve Views of Mark Jason Dominus:
\n\n\nI released the Text::Template module several years ago, and it was immediately very successful. It's small, simple, fast, and it does a lot of things well. At the time, there were not yet 29 templating systems available on CPAN.
\nAnyway, the module quickly stabilized. I would get bug reports, and they would turn out to be bugs in the module's users, not in the module; I would get feature requests, and usually it turned out that what the requester wanted was possible, or even easy, without any changes to the module. Since the module was perfect, there was no need to upload new versions of it to CPAN.
\nBut then I started to get disturbing emails. \"Hi, I notice you have not updated Text::Template for nine months. Are you still maintaining it?\" \"Hi, I notice you seem to have stopped work on Text::Template. Have you decided to abandon this approach?\" \"Hi, I was thinking of using Text::Template, but I saw it wasn't being maintained any more, so I decided to use Junk::CrappyTemplate, because I need wanted to be sure of getting support for it.\"
\nI started wondering if maybe the thing to do was to release a new version of Text::Template every month, with no changes, but with an incremented version number. Of course, that's ridiculous. But it seems that people assume that if you don't update the module every month, it must be dead. People seem to think that all software requires new features or frequent bug fixes. Apparently, the idea of software that doesn't get updated because it's finished is inconceivable.
\nI blame Microsoft.
\n
I must confess that I tend to look at the date of the last commit when I choose a library over another (along with other metrics, hopefully).
\nWell, I also think that a \"perfect library\" might not exist, but the author is making a really good point in his talk.
\n(via What if we had more finished libraries?)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-08-21T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/06/ads/", "url": "https://matthieuoger.com/2015/06/ads/", "title": "The Web, the Ads and the Ad-Blockers", "content_html": "Like almost everyone else, I don't like ads. Nevertheless, I don't use an ad-blocker either.
\nUsing the web and using an ad-blocker is hypocrite. Like it or not, it's the most widely used business model on the web. That's how most people get paid for the content you read, watch and listen for free.
\nThere're other ways to do it (affiliate links, feed sponsorships, paywalls, etc.), but the dominant model today is ads.
\nYou know what? I don't find ads particularly irritating from now on. Why? Because I find and read honest websites that respect me by not throwing huge walls of ads to my face. I avoid those ad-filled websites, because most of the time, they are simply bad. And for YouTube? I patiently wait because the great contents made there that I want to see deserve to be paid.1
\nThe solution is not ad-blocking. The solution is to find well-made contents which focus on the readership, not the publisher.2
\nLet me finish with this:
\n\n\nThere is a huge irony in that fact that AdBlock's function of keeping ads away from our content will eventually do the opposite. The alternative to ads alongside my content is ads inside my content.
\nLet's face it: paywalls don't work. The alternative on the horizon is native advertising. Buzzfeed is now famously refusing to host ads. Instead they sustain themselves by publishing content that subtly supports the agenda of any company with deep enough pockets to pay for it. A viewer's ability to distinguish between native ads and regular articles is small and quickly vanishing. If separate ads stop reaching people, the path to monetization remaining is to change your content to reflect someone else's agenda.
\n
Because you cannot distinguish an ad from an article, it's even more insidious and dishonest. And this time, you won't be able to block it.
\nMy view on this has changed quite a bit recently. With the explosion of ad tracking technologies and the bloat they add to any webpage, I do use an ad blocker now. But only with Safari, where I find it safe to use an extension like that thanks to its \"Content Blocker\" model of security (ie., no access to the page content, just many rules that match the webpage without a way to send data back).
\nI have absolutely no trust in a company like AdBlock, and I am not willing to give them my data so easily.
\nI do, however, unblock some specific sites. It's a shame, though.
\nForce Touch is an impressive piece of technology. It currently equips the Apple Watch and the new Macbooks. You press firmly on the screen and the haptic engine will register a \"deep\" press.
\nOn the Watch, I found that the feedback was not properly mapped to the press (it's a tap on your wrist, not on your finger). I didn't use the Watch a lot, but I've also found that it was sometime hard to trigger.
\nOn the new Macbooks' trackpad, the feeling is fantastic. You can push multiple times and sense the force you apply like it's real. You may not even understand that it's not a true physical button.
\nBut… Force Touch is not discoverable.
\nThere is no visual clue that Force Touch is available — either on the screen or on a specific control. It's like the menu button of the old Android versions: you tap somewhere (the menu button on Android, firmly with Force Touch) and something may happen. Or not. It's confusing and it's one more hidden gesture with no affordance. It's no better than a long press if its sole purpose is to be another context menu.
\nIndeed, on the Apple Watch, Force Touch's goal is to show a secret menu with additional actions. I understand the purpose — the screen is small and you can't fit everything on the screen. But this exact same behavior on a bigger display will have the same problem that Android had with its menu button. It's even worse than a hamburger menu, because the icon won't be there to tell you that an additional layer is present.
\nOn OS X, I found that the usage of Force Touch is better: it's not a way to show secondary actions, but just a \"deeper version\" of an action. In QuickTime, for example, you press firmly on the forward button and the video will fast forward faster for each level you reach. It's still hard to know when it's available and might result in nothing, but at least, it's consistant with its source.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-06-08T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2015/04/space-odyssey/", "url": "https://matthieuoger.com/2015/04/space-odyssey/", "title": "Space Odyssey", "content_html": "I've finally convinced myself to watch 2001: A Space Odyssey.1
\nN.B.: If you haven't seen it, I don't think you should read what's coming. Spoilers ahead.
Well. I didn't love the movie (the pace is really slow, even for a movie from the sixties, and not being a fan of classical scores might not have helped). I don't mind if a film is ambiguous or doesn't explain much, but 2001 may have gone a bit too far.
\nI get that the monoliths are alien artifacts (or an alien race). I get that David Bowman has been translated in a sort of zoo. I vaguely understood that the Star Gate is a kind of allegory about the human reproduction (there's even a foetus and an umbilical cord during this passage — and the Star Child coming back to earth can also be seen as a birth). But why? Why does an extraterrestrial race would want to improve another race? Why use monoliths? Why would they open the gate near Jupiter and not on the moon?
\nThe HAL sequence was perfectly clear however, even if they don't explain why it was malfunctioning (it doesn't matter). An interpretation talks about the duality between being a perfect computer and having to lie to the crew about the origin of the mission — this would create a paradox inside the machine. I like that idea.
\nWhat, in the end, annoyed me the most were the expections I had. I always thought that the story would be phenomenal. And… it's not, really. It's pretty simple as soon as you think about it (not having explanations don't change that fact — it just wraps the movie in more mysteries). I had the same reaction after finishing Blade Runner, a few years ago.
\nIt's not the movie's fault: every awesome idea it invented has been reused everywhere since.
\nI was pleasantly surprised to find that the movie does not feel that dated: the images are still beautiful and the depiction of space is really well-done (especially for its time).
\nWhat I loved about the movie is some of the possible interpretations. I'm really eager to read the novel by Arthur C. Clarke to dive a bit more into the story. Especially for this theory:
\n\n\nArthur C. Clarke's theory of the future symbiosis of man and machine, expanded by Kubrick into what Wheat calls \"a spoofy three-evolutionary leaps scenario\": ape to man, an abortive leap from man to machine, and a final, successful leap from man to 'Star Child'.
\n
I've also found a great quote by Stanley Kubrick about intelligent life when I was reading articles about the movie:
\n\n\nI will say that the God concept is at the heart of 2001 but not any traditional, anthropomorphic image of God.
\nI don't believe in any of Earth's monotheistic religions, but I do believe that one can construct an intriguing scientific definition of God, once you accept the fact that there are approximately 100 billion stars in our galaxy alone, that each star is a life-giving sun and that there are approximately 100 billion galaxies in just the visible universe. Given a planet in a stable orbit, not too hot and not too cold, and given a few billion years of chance chemical reactions created by the interaction of a sun's energy on the planet's chemicals, it's fairly certain that life in one form or another will eventually emerge.
\nIt's reasonable to assume that there must be, in fact, countless billions of such planets where biological life has arisen, and the odds of some proportion of such life developing intelligence are high.
\nNow, the sun is by no means an old star, and its planets are mere children in cosmic age, so it seems likely that there are billions of planets in the universe not only where intelligent life is on a lower scale than man but other billions where it is approximately equal and others still where it is hundreds of thousands of millions of years in advance of us.
\nWhen you think of the giant technological strides that man has made in a few millennia—less than a microsecond in the chronology of the universe—can you imagine the evolutionary development that much older life forms have taken? They may have progressed from biological species, which are fragile shells for the mind at best, into immortal machine entities—and then, over innumerable eons, they could emerge from the chrysalis of matter transformed into beings of pure energy and spirit.
\nTheir potentialities would be limitless and their intelligence ungraspable by humans.
\n
It was one of the greatest shame of my movie culture. Especially when considering the fact that I love science-fiction books and films.
\n↩\nFor a few reasons, I'm considering whether or not I should be buying an Apple Watch.1
\nFor many people I know, it's another useless gadget.
\nThat's fine: most people are sceptical about new technologies, after all. It's in our nature: human doesn't like change (and new things) until it reaches a certain threshold and becomes acceptable. And to be fair, it might just be a fad.
\nThe iPhone (and other touch-based smartphones) were also considered as useless gadgets in their beginnings too — almost everybody has a smartphone now, right?2
\nBut like the iPhone, there's a chance the Apple Watch will succeed and become a thing (that's a big if, but I'm still more inclined to believe it will than not).
\nFor the moment, I don't think there're many usages that make a watch (or other wearable devices) truly better than a phone. Hopefully, we are only at the beginning. To understand what we can do as developers, we have to use those objects daily.
\nThat's not to say they are completely useless as of today.
\nThe usages that intrigue me the most are:3
\nBut not notifications.
\nI'm a huge proponent of disabling almost all notifications.
\nI restrict the apps that can send notifications to the bare minimum (SMS, calendar, reminders and that's most of it) because I think that notifications are a nuisance.
\nYou don't need to know when someone followed you on Instagram or Twitter. You don't need to be interrupted when you receive a mail. That's also why I'm even more aggresive against sound for notifications (I do receive my mail every hour, but silently). I'd rather grab my phone and act willingly on something than being always distracted.
\nPeople who are flooded by notifications (like tech reviewers) and criticize a device because of that ARE the issue, not the device. A wearable will only make their problem worse, because they will also allow access to those nuisance to a device that is physically connected to their body. And which can tap them anytime.
\nWhat is really making sense is to have quick pertinent contextual information available at a glance.
\nLike, when your train is ready to leave — which platform, what seat? That's useful: you are in a urge, you walk quickly and taking your phone out of your pocket takes time and precision.
\nHaving your itinerary directions given to you by a few vibrations? That's great too.
\nHaving a full-fledged Twitter app on your wrist? Useless. Getting your Facebook likes instantly? Useless.4
\nI'm interested in wearables (when they are not socially awkward) because of what they might become. What they are today is just a glimpse of the potential of such devices.
\nImagine the application in the health field: with sensors on your body, it could be really easy to know and track diseases. To go there, we need to start small. For the moment, that means a watch with an heartbeat sensor and 18 hours of battery life.
\nI probably won't, for the moment. Priorities.
\n↩\nBenedict Evans in “New Questions In Mobile”:
\n\n\n↩\nAcross all of this, and far more important, we are now well on our way to having some 3.5bn to 4bn people on earth with a smartphone. […] For the first time ever, the tech industry is selling not just to big corporations or middle-class families but to four fifths of all the adults on earth - it is selling to people who don’t have mains electricity or running water and substitute spending on cigarettes for mobile.
\n
The watch feature is probably the less important feature of a smartwatch. It's handy like it is on a phone. But like the phone feature of a smartphone, it's not the decisive capability.
\nGo on people, make jokes about a watch that is only able to tell the time for a day before running out of battery. ;)
\n↩\nBut that's also true for the web or an app, to be honest.
\n↩\nFantastic interview of Loren Brichter on objc.io:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2015-01-15T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2014/12/a-tiny-game-that-you-can-play-forever/", "url": "https://matthieuoger.com/2014/12/a-tiny-game-that-you-can-play-forever/", "title": "A Tiny Game That You Can Play Forever", "content_html": "The more I learn, the more terrible I think programming is. I’d love to rip everything up and start over. But you can only swim against the tide so far, so it’s sometimes satisfying to sift through the garbage and repurpose terrible technologies to make something that is slightly less terrible. […]
\nIt’s not like a boat with a couple of holes that we can patch; it’s more like trying to sail across an ocean on a pile of accrued garbage. Sure, some of the stuff floats, and it keeps some other stuff from sinking. A better question might be: which parts are good? And you can only answer that if you look at a thing in isolation.
\n
The Up Up Down Down podcast has a good episode with Asher Vollmer.
\nA Tiny Game That You Can Play Forever:
\n\n\nAsher Vollmer, creator of Threes and Close Castles, joins us to talk puzzle games. We discuss the process of designing developing Threes, and what goes in to making a great little puzzle game. We then talk about the whimsical minimalism that works so well in indie games, and how to bring them to life. We talk about difficulty, complexity, and how to tune games. We touch on the effects of free to play on puzzle games, and how it makes us feel weird.
\n
There're some great points in there. It focuses a lot on Threes' gameplay and evolutions and dives a bit more into minimalism in games.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2014-12-19T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2014/08/taking-a-break/", "url": "https://matthieuoger.com/2014/08/taking-a-break/", "title": "Taking a Break", "content_html": "I'm self-employed and I work every day at home for my company, Pixelnest Studio.
\nA common good practice recommended by almost any home-worker is to take a quick (3 minutes) walking break every 45 minutes or so.
\nIt's a simple habit, but it's hard to get used to it. For the last weeks, I forced myself to walk for 3 minutes every 1 hour of work.
\nAnd… it's great. I'm really feeling much more concentrated and ready.
\nBecause I will forget to stand up as soon as I'm working, I've made a little \"app\" for OSX. In fact, it's just a simple automator app that will trigger a notification for three minutes. Follow the gist above to know how to use it. It's dead simple, but it works.
\nNB: this advice is especially true for self-employed people (because you can't take a break with your coworkers), but anybody working at a desk for several hours should do it. It costs nothing, and your body will love it.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2014-08-01T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2014/06/design-detail-ios8-messages/", "url": "https://matthieuoger.com/2014/06/design-detail-ios8-messages/", "title": "Design Detail in iOS 8 Messages", "content_html": "One of the features that I wanted the most in iOS 8 was simple: add a “Use Last Photo Taken” button in the Messages app (along with the current \"Take Photo or Video\" and \"Choose Existing\").
\nThe idea was originally thought by Neven Mrgan and later adopted by a lot of apps (Tweetbot, Slack, Droplr, etc.).
\nBut it was still missing in the one place where it would definitely shine: Messages.
\nNo more.
\nThe way it was added is brilliant. It's so simple that I don't know why it hasn't been done already (it might, I just don't know of an app that have done that).
\nHere it is:
\nIt solves three problems:
\nYou can see the last photo and be sure of what you are doing BEFORE doing it.
\nWith a button, the app had to provide a way to check the action.
\nIn Tweetbot, for example, the compose view shows a small thumbnail of the image.
\nIn Droplr, it's too late. As soon as you tap the button, the photo is uploaded and you have to delete it to fix your error.
\nIt's so simple and clever that once you have seen it, you can only think: \"Of course.\".
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2014-06-03T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2014/01/how-netflix-reverse-engineered-hollywood/", "url": "https://matthieuoger.com/2014/01/how-netflix-reverse-engineered-hollywood/", "title": "How Netflix Reverse Engineered Hollywood", "content_html": "Alexis Madrigal on Netflix classification:
\n\n\n[…], we discovered that Netflix possesses not several hundred genres, or even several thousand, but 76,897 unique ways to describe types of movies. […]
\nUsing large teams of people specially trained to watch movies, Netflix deconstructed Hollywood. They paid people to watch films and tag them with all kinds of metadata. This process is so sophisticated and precise that taggers receive a 36-page training document that teaches them how to rate movies on their sexually suggestive content, goriness, romance levels, and even narrative elements like plot conclusiveness. […]
\nThe Netflix Quantum Theory doc spelled out ways of tagging movie endings, the \"social acceptability\" of lead characters, and dozens of other facets of a movie. Many values are \"scalar,\" that is to say, they go from 1 to 5. So, every movie gets a romance rating, not just the ones labeled \"romantic\" in the personalized genres. Every movie's ending is rated from happy to sad, passing through ambiguous. Every plot is tagged. Lead characters' jobs are tagged. Movie locations are tagged. Everything. Everyone.
\nThat's the data at the base of the pyramid. It is the basis for creating all the altgenres that I scraped. Netflix's engineers took the microtags and created a syntax for the genres, much of which we were able to reproduce in our generator.
\n
This article completely blew my mind. Great journalism.
\nThe idea to tag any movie that much and create ultra-specific subgenres is so clever. Hell of a work too.
\nConcerning the Perry Mason mystery, I found an interesting explanation in the comments (yep):
\n\n\nActually, Alexis, I am baffled by your conclusion that the Perry Mason Mystery is a \"ghost in the machine\".
\nTo me it seems obvious: there is a subgenre, \"Understated Cerebral Mysteries with Ironclad Plots, Good Dialogue, Not Much Action or Romance, and on the Side of the Defense\", that is popular with viewers yet drastically underpopulated. It's so drastically underpopulated that the show that's a best-fit for the category is enormously popular, much more popular than anyone realized.
\nFar from being a \"bug\", this is programming platinum for Netflix. If they're as smart as I think they are, this is the subgenre where they should be looking to make a TV series. The biggest problem will be finding a showrunner and scriptwriters who are able to go against so many of Hollywood's cliches and assumptions. They need to make something where what is visually interesting, striking, or exciting is unimportant, but where there are no holes in the plots. Very high degree of difficulty, and only profitable to Netflix, which makes money from its shows, not from the advertising.
\n
Sounds a bit like Sherlock, no?
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2014-01-07T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/11/unity-2d-tutorial/", "url": "https://matthieuoger.com/2013/11/unity-2d-tutorial/", "title": "Unity 2D tutorial", "content_html": "During the last weeks, we (Damien and I) have cooked a complete tutorial about Unity and its new 2D tools. This tutorial covers the creation of a very small game from start to finish.
\nWe hope you will enjoy it.
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-11-21T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/10/how-designers-destroyed-the-world/", "url": "https://matthieuoger.com/2013/10/how-designers-destroyed-the-world/", "title": "How Designers Destroyed the World", "content_html": "Better late than never; I've managed to watch “How Designers Destroyed The World” by Mike Monteiro.
\nIt's a great talk except that I'm not fond of the tone. Though it fits well with the content, I find it a bit overdramatic. The end is also a tad lengthy, which is unfortunate.
\nOtherwise, I liked what I heard. Which makes me consider…
\nRegularly, I find myself stuck with incredibly ill-conceived things that frustrate me. These objects, rules or designs are things as simple as an ATM, a software or a door. They make us loose time, or worse, do (severe) mistakes.
\nFor example: there is a crossroad near my parents house. A few years ago, the mayor decided to remove the road signs at this place AND to not replace it. In France, there is an implicit rule which states that when there are no signs, you have to let the cars at your right cross the junction first. This rule is stupid. When you drive, you have no time to doubt. A sign serves primarily as way to convey a danger or a rule, without making you think. You know what you have to do instantly. If you see a stop sign, you stop. That is all.
\nThis implicit rule makes us do the contrary. At a junction like the one I talked about before, you see nothing, so you have to think, analyze and react. It's easy to have a (minor) car accident there. Moreover, people of my town had used this junction for years, knowing precisely how to react. But now, the priority rule has changed, and it's a mess. The result? In the best case, everybody stop, wait for 10 seconds to analyze the place and then drive.
\nThis is a result of a design decision. Someone decided to do that. In this case, someone decided to break something that worked well for all this time.
\nSometimes, it might just be a dumb design that put you in an embarrassing situation. If you are a man, just remember the last time you have used a flat and too-high urinal. :)
\nWhen I talk about that with some of my friends, they think that I'm excessively demanding and that the problem is me. Perhaps.
\nI will conclude with a quote from the talk:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-10-22T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/10/you-must-prototype-it-in-code/", "url": "https://matthieuoger.com/2013/10/you-must-prototype-it-in-code/", "title": "You Must Prototype It in Code", "content_html": "There are professions more harmful than (industrial) design, but only a very few of them.
\n
Jeff Atwood in Good Programmers Get Off Their Butts:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-10-18T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/09/paying-for-softwares/", "url": "https://matthieuoger.com/2013/09/paying-for-softwares/", "title": "Paying for Softwares", "content_html": "I am not proposing a code-like-hell methodology. I am merely observing that, in my experience, coding without planning is just as futile as coding with too much planning. Software development is a wicked problem; you should never make planning decisions without some kind of code prototype to ensure that you're making informed decisions. If you plan too far ahead of the code, I guarantee you are doing work that will be thrown away or altered until it is unrecognizable.
\nThe most destructive symptom of over-planning is the wrongheaded idea that being a Software Architect™ means drawing a lot of UML diagrams and handing them off to a group of developers in Bangalore. UML is great if you don't want to do any work; you just draw pictures of what it would look like if work was actually done. This is not only borderline laziness, it's also a recipe for disaster. You can't architect a real world application on a whiteboard. You must prototype it in code to gather data on the performance and design implications of the choices you are making.
\n
Florian Kugler about mobile apps in Worth Less than a Cup of Coffee:
\n\n\n[People] might say otherwise when asked about, but their actions speak pretty clearly: A cup of coffee is worth more than almost every app on the store.
\nThat's a hard pill to swallow, but we should let it sink in. We pour all our creativity, time, and passion into creating basically worthless products.
\n
Recent events and the backlash against Realmac with Clear for iOS 7 are sad.
\nPeople don't understand that creating softwares — truly good softwares that sweat every detail — takes a lot of time and money. Ironically, even a lot of developers who work in big companies don't want to pay for softwares.
\nThe mobile apps markets have made this situation worse.
\nI'm currently thinking back about the mobile market, especially for games. At a time, I thought that going mobile-only was the best shot today, but the more I think about it, the more I'm realizing that a platform like Steam (which also drives the prices to the bottom, alas) is more sustainable for a developer/company.
\nMarco Arment said in its latest blog post: \"Paid-up-front iOS apps had a great run, but it’s over. Time to make other plans.\".
\nSo what does that leave? Freemium? Unfortunately, freemium almost always goes with bad apps or games that trick users to pay for more.
\nN.B.: To be clear, as a user, I'm happy to pay less. For almost everybody, a software or a game at 50-100$ is way too high, and that's fine. What I don't like is that we are now in a situation where even one buck for an app you use daily is too much. One buck per app cannot sustain a one-person business.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-09-30T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/09/patent-trolls/", "url": "https://matthieuoger.com/2013/09/patent-trolls/", "title": "Patent Trolls", "content_html": "Angry entrepreneur replies to patent troll with racketeering lawsuit:
\n\n\n\"There's a lot of outrageous stories, but everyone's so damn afraid of coming forward—It's like going against the Mafia,\" he said. But the idea that trolls may retaliate against those who speak out is overblown, he thinks. \"If they want to try to teach me a lesson, go for it. This will be my retirement. I'll fight them.\"
\n
Here it is:
\nInteresting system.
\nI'm not against patents and inventors' rights. But there is a big difference between protecting your properties from real thieves and suing everyone without actually creating anything.
\nHowever, if the only solution to this problem is to abolish the patents system, so be it.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-09-17T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/09/brand-and-logo/", "url": "https://matthieuoger.com/2013/09/brand-and-logo/", "title": "Brand and Logo", "content_html": "Fantastic essay by Oliver Reichenstein:
\n\n\nThis post is not about the technical quality of the logo. I am not writing about brand design, but about brand management. This is about a simple rule: Brand design follows brand management, not the other way around.
\nOne could argue that we can’t say if this is bad brand management. Unless we know what the brand ambition, the brand architecture, and the brand strategy is, we ought to have no opinion. Maybe the logo does exactly what it is supposed to do. Because really, it doesn’t matter whether it looks pretty, or whether someone likes or dislikes the purple or the scallops. The Coca-Cola logo was not designed by a professional designer, it is typographically hideous, but that doesn’t matter. Brand identity is not about visual refinement or aesthetics. It can be purposely ugly, like the London Olympics logo. What is important is that it is done seriously.
\n
(By the way, I'm still amazed by the quality of the iA website, and especially the blog. Typography, details, everything. It's wonderful.)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-09-11T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/09/microsoft-out/", "url": "https://matthieuoger.com/2013/09/microsoft-out/", "title": "Microsoft Out", "content_html": "Great article by Charles Miller about Microsoft fall:
\n\n\nMicrosoft did not make its mark as a builder of great things, but as a very successful bundler of good-enough things. […]
\nEventually by the mid-90s an argument could be made that Microsoft was making the best PC software in its class. Not because it had suddenly found the ability to develop cool, innovative products, but because everyone else was dead. […]
\nStill, outside that monopoly, there is a clear distinction between Microsoft products that can trace their market dominance back to DOS, and those that can't. The former make money, the latter lose it.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-30T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/the-gif-video-format/", "url": "https://matthieuoger.com/2013/08/the-gif-video-format/", "title": "The Gif “Video Format”", "content_html": "But the 2DS just isn’t made for people like me. That doesn’t mean it’s going to fail. That doesn’t mean it’s a bad product. It just means it’s not for me.
\nAnd this, finally, brings all of this back to the topic of design. If you want to design a successful product, don’t design a product that’s only good for people like you, because most people aren’t like you.
\n
HTML video still can't beat GIF:
\n\n\nAnimated GIF, despite having awful compression and terrible quality, is still more useful on the web than any other video format.
\nIn 2013 people still routinely convert YouTube clips to GIF (producing postage-stamp-sized dithered-to-death desaturated blobs that use more bandwidth than a full HD video), because there's still no better way to share a short movie clip on the web.
\n
Gifs are an abomination: they are heavy and the quality is, most of the time, terrible. However, their convenience is too good that people use them nonetheless.
\nThe electrical cost of gifs must be gigantic.
\nThere's hope. In a near future, and in other browsers than Safari, we will be able to use a video as an image to simulate a gif (ie., silence and autoplay). With perks of a video instead of an awful low-quality and heavy gif.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-29T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/amazon-new-product-page/", "url": "https://matthieuoger.com/2013/08/amazon-new-product-page/", "title": "The Work of Change", "content_html": "Interesting article on Bokardo about Amazon's \"new\" product page:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-28T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/quote-trent-reznor/", "url": "https://matthieuoger.com/2013/08/quote-trent-reznor/", "title": "Paying for Things", "content_html": "\nIf Amazon were to make a big change, like for example do some actual visual design so everything didn’t have the same visual weight, the mere shock of the change would probably send their revenue downward, at least initially. People dislike change because change is work. They have to figure out what changed, adapt to it, relearn the UI, and still try to get their job done (they one they used to know how to do). So the next time you hear “People hate change” think to yourself “People don’t hate change. They hate the work of change”.
\n
\n\nI'm not saying offering things for free or pay-what-you-can is wrong. I'm saying my personal feeling is that my album's not a dime. It's not a buck. I made it as well as I could, and it costs 10 bucks, or go fuck yourself.
\n
(via ParisLemon)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-28T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/quote-jonathan-blow/", "url": "https://matthieuoger.com/2013/08/quote-jonathan-blow/", "title": "Ads Influence", "content_html": "\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-27T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/team-of-one/", "url": "https://matthieuoger.com/2013/08/team-of-one/", "title": "Team of One", "content_html": "Advertising is effective only because so many people think “Ads don't influence me” and “Ads give me what I want for free”.
\n— Jonathan Blow (@Jonathan_Blow)
\n
There's no \"I/O\" in \"Team\":
\n\n\nWhen you're a team of one, your I/O bandwidth is almost infinite. It's all in your brain, so you don't have to explain anything, write anything down, have meetings, draw on whiteboards, etc. Your available time to work collapses down to solving specific business problems with every line of code or web page update. Imagine a case where you never have to compromise, argue, make brain dead concessions or spend resources on proving your position. Assuming you are right, and have a good head for business, marketing and writing half-way decent code, you can solve a small problem very efficiently.
\n
Hard but hyper-efficient.
\nWe work a bit like that at Pixelnest. Damien and me have a slightly different skill set, thus we can split the work almost equally. The advantage is that we can discuss together to avoid finishing in a dead end.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-19T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/transitional-interfaces/", "url": "https://matthieuoger.com/2013/08/transitional-interfaces/", "title": "Animations, Interactions, Transitions", "content_html": "\n\n\nIt seems crazy to me that more people don’t think about interfaces with respect to the dimension of time. Motion can provide so much information! Maybe the tools to create prototypes are too complicated for most designers?
\n
This is something I always speak about: an interface without motion is nothing. There is no context, no link between different objects.
\nWindows Phone did a great job to this regard. For example, if you tap a tile on the homescreen, the rest of them move outside the screen before the one you pushed. The system has clearly been created around that, to respond to inputs and act on them.
\nMotion is clearly a thing that designers tend to forget. Even if an interface is beautiful, it will look dull if nothing reacts to you. The \"flat\" design movement will exacerbate this. iOS 7 has made depth and context keys citizens of its new UX paradigm.
\nTools to simplify this process are now crucial.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-14T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/marketers/", "url": "https://matthieuoger.com/2013/08/marketers/", "title": "Marketers", "content_html": "“Hey Marketers, making a website is not about you”:
\n\n\nThe problem with many Marketers today is that they too often make it all about the company, and not about user needs. I’m sorry, but it’s not about changing people, and it’s not about making them do stuff. That’s old school thinking from a time when brands could steamroll their way into the consciousness and wallets of people through clever advertising and sleight of hand. Those days are over. Now our job is not to make it about how awesome we are, but how well we help people accomplish their goals.
\n
Further readings related to this subject:
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-13T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/zero/", "url": "https://matthieuoger.com/2013/08/zero/", "title": "Zero", "content_html": "\n\n\nEveryone works differently. The trick is finding out how you work best. For me, I tend to take an OCD approach to emptying things. I keep a clean desktop: under three icons at a time, preferably. It made sense to use my desktop as a kind of bucket I needed to empty: it's always there, and I can put short, actionable items there because that visually disturbs me enough to want to clean it off (and do the action).
\nThis is why Inbox Zero works so well for handling email for me. I try to use that mentality everywhere, really: iOS notifications, browser tabs, terminal tabs, and so on. Reducing ambiguity around what to do next is a huge deal for me.
\n
I have a similar mindset. I hate having stuffs in front of me:
\nA sort of minimalism? Probably.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-09T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/future-programming/", "url": "https://matthieuoger.com/2013/08/future-programming/", "title": "The Future of Programming", "content_html": "I finally watched the latest Brett Victor's conference: The Future Of Programming. I highly recommend to check everything he has done. You will not loose your time.
\nOne of the moments I liked the best is when Brett Victor is talking about smalltalk and its browser view. This idea, that is fairly old now, reminds me of some initiatives like Brackets or Light Table. These editors are still using text files to manage code, but they add inline code browsing or live feedback, amongst others. It is funny to see that we had to wait 40 years to see that happens.
\nWhich reminds me of the conclusion of Brett Victor: you have to realize that you do not know what you are doing in order to find new way of doing things.
\nIn the programming field, we have improved our tools, but globally, we are still doing the same thing: coding with text files. That's sad.
\nA theme that comes in almost all the Brett Victor's talks is live feedback. Just watch Inventing on Principle.
\nI have used Interface Builder a lot recently — a software to create interface for iOS apps —, and even if this tool is one of the best of its kind (I look at you Android, with your stupid XML UI files), it is not a good one for all that.
\nIt gives me a partial representation of my interface: I cannot do everything with it. I cannot see animations. I cannot see particles. I cannot test the physic (and physic is clearly one of the key points of the new iOS 7 interface). I loose a lot of time checking that what I have done in code and Interface Builder are really what I want. It is tedious. It is slow.
\nWe need better tools to create UI — we need feedback and interactivity directly within the creative process.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-06T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/os-wp-winrt/", "url": "https://matthieuoger.com/2013/08/os-wp-winrt/", "title": "Windows Phone and WinRT", "content_html": "From Windows Phone or Windows RT?:
\n\n\nMicrosoft already has a mobile platform with a thriving ecosystem. It’s called Windows Phone, and I think it makes a far better choice for general purpose tablets than does Windows RT.
\n
I used to have a Nokia Windows Phone, that I loved. The experience was pretty good, except for the lack of apps.1
\nI created some Windows Phone 7 applications (notably Culturez-Vous with Damien Mayance). I also developed a WinRT library for my daily work then — before Pixelnest.
\nI had a Windows 8 and a WinRT device (Surface) at my workplace these days, and it was horrible. The experience was bad — the OS was a schizophrenic beast, always switching between the classic desktop and the Metro environment, with no apps. It was slow, unrefined, confusing. The font rendering was horrid.
\nWhen the announcement of WinRT became public, I wondered why Microsoft did not leverage its Windows Phone OS, instead of starting from scratch with Windows 8. A tablet with Windows Phone would have been far better than a tablet with the fail that is WinRT/Windows 8.
\nTo be fair, however, even then I thought that iOS was a superior OS. But I like to try a new OS to discover what works and not, and to make my own opinion.
Windows Phone lacked some polish but was rock solid, especially when compared to Android. At least, the Lumia was a supercharged feature phone with a browser and a decent keyboard.
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-05T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/life-too-short-ugly-graphs/", "url": "https://matthieuoger.com/2013/08/life-too-short-ugly-graphs/", "title": "Life Is Too Short To Stare at Ugly Graphs — and Yes, You Should Feel Bad", "content_html": "\nI offered to give my Nexus 7 and Kindle Fire to Betaworks in the Instapaper acquisition, but they had so many of both sitting around already that they declined. Tech companies with mobile apps can practically tile walls with outdated Android devices. They’re the new AOL CDs.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-02T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/08/quote-changing-the-world/", "url": "https://matthieuoger.com/2013/08/quote-changing-the-world/", "title": "Changing the World…?", "content_html": "\nIt was done in-house. We really care about how our graphs look, because graphs represent information. It's like typography. Humans learned how to write 5000 years ago, and it took us a very long while until we mastered the art of transmitting information like that. Once we mastered it, however, we started caring about the way we present that information. For no specific reason, but we developed unique typefaces that look beautiful, different, yet transmit the same information.
\nLikewise, we've spent a ton of valuable time graphing and mining data from all over our stack; it's only natural that after that, we care about how we present that data. Like typography, it's hard because it's an arduous hunt for the aesthetics hidden behind information. But this hunt is what makes us human.
\nThat's why we design beautiful graphs, just like we'd design a beautiful typeface. Not because we are GitHubbers, nor because we are designers, but because we are humans.
\nLife is too short to stare at ugly graphs. And yes, you should feel bad.
\n
\n\nCould \"changing the world\" be a contender the most trite, overused expression of 2013? Recent grads seem to have adopted it en masse as their personal tagline. It's a nice sentiment, but it hard not to roll your eyes when every 23 year old applies it to his mobile phone app with no users that he threw together in a couple weeks.
\n[…]
\nBesides, I'm not even sure it's a healthy sentiment for most people. If your focus is as broad as \"changing the world,\" you're probably setting yourself up to feel like a failure.
\n
(via Wolf's Little Store)
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-08-02T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/07/designer-decision/", "url": "https://matthieuoger.com/2013/07/designer-decision/", "title": "Designer's Decision", "content_html": "Ben Howdle, in “Options Are The Devil”:
\n\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-07-25T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/07/rule-three/", "url": "https://matthieuoger.com/2013/07/rule-three/", "title": "The Rule of Three", "content_html": "\nIt’s kind of like going, “Well, erm, I dunno, this is a tricky UI/UX decision, oh hell, we’ll let the user decide.” Passing the buck to the user to make the UX decision for you? Sounds worse when it’s put like that, huh?
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-07-24T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/07/current-days-science-fiction/", "url": "https://matthieuoger.com/2013/07/current-days-science-fiction/", "title": "Current Days Science Fiction", "content_html": "\nIf I have learned anything in my programming career, it is this: building reusable software, truly reusable software, is an incredibly hard problem – right up there with naming things and cache invalidation.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-07-23T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/07/quote-brent-simmons/", "url": "https://matthieuoger.com/2013/07/quote-brent-simmons/", "title": "Efficiency Is Superior UX", "content_html": "\nMicrosoft struggles to get developers on its platforms with apps coming late or not at all, developers ship for Apple first and foremost and the platform with the most market share is, ostensibly, open-source.
\nYou couldn’t have written this as science fiction in 1997. No one would have believed it.
\n
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-07-02T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/07/firefox-os/", "url": "https://matthieuoger.com/2013/07/firefox-os/", "title": "Firefox OS", "content_html": "Efficiency is more important than cloning Google Reader’s (undocumented and un-lovely) API and more important than adhering strictly to REST. (Because efficiency makes for a better user experience, and that’s more important than anything else.)
\n
Mozilla and Telefónica have announced a phone running Firefox OS this morning - the ZTE Open. It will cost $69.
\nMozilla, as usual, promotes the open nature of its OS along with the fact that it is powered by web technologies:
\n\n#FirefoxOS arrives this month in select markets! Celebrate the 1st smartphone powered completely by Web technologies! http://t.co/Mio0f4zctj
— Firefox (@firefox) July 1, 2013
I honestly don't get it:
\nI would like to be wrong, but I don't expect much and I don't see the value of Firefox OS, especially against its main competitor — Android. There are Android phones that are cheaper AND with Google Play.
\nI agree with Benedict Evans:
\n\nWhen I hear people say how great Firefox OS is, they talk about operators, OEMs, litigation... and sometimes remember to mention users
— Benedict Evans (@BenedictEvans) July 1, 2013
And:
\n", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-07-01T00:00:00.000Z" }, { "id": "https://matthieuoger.com/2013/06/a-start/", "url": "https://matthieuoger.com/2013/06/a-start/", "title": "A Start", "content_html": "Everyone agrees that the web is the future and apps are a dead end. The only people who disagree are the actual, you know, users.
— Benedict Evans (@BenedictEvans) July 1, 2013
For years, I was eager to create my own writing \"platform\".
\nSo, I guess it starts now.
", "author": { "name": "Matthieu Oger", "url": "https://matthieuoger.com" }, "date_published": "2013-06-26T00:00:00.000Z" } ] }