1. 9

    Probably a coincidence. I’m not sure if an organization the size of Facebook can design, program, test and deploy to production anything in just four days.

    1. 4

      They could surely go ahead and approve something that had been stalled for a while.

      Side thought: I happened to view a Facebook page via mbasic for the first time today and that happened before reading this thread. I can’t figure out how that could support the theory of coincidence, but some part of my mind is very eager to find a connection–any connection. Such is our nature.

      UPDATE: I meant to say “I can’t figure out how that could support the idea that it was merely a coincidence …”.

      1. 1

        I think it is easier to read coincidences if mind open to the idea that there is much about the workings, composition, and population of our universe that we not only don’t understand, but may not even imagine are there.

      2. 3

        They used to do just that. That was the whole “move fast and break things” slogan. They have or had an incremental rollout feature where they can or could try just about anything and very quickly test it on 1% of their userbase or whatever.

        I’m not sure if they’ve listened to the ethical implications of using some of their own users as unwilling beta testers or not, but they were quite public about how they have done this in the past.

        1. 2

          Every organization with a large enough userbase that cares about uptime does incremental rollouts.

        2. 2

          I’m not sure of the scope of the changes, but if it was a relatively small set of fixes like correctly rendering event titles on the mbasic Upcoming Events page, most FB engineers could do that with less rollout time than four days. Definitely could’ve been (probably was?) coincidental, but it wouldn’t be totally surprising to me if it wasn’t.

          (I work at Instagram.)

        1. 12

          I think of Material Design more of a safety net. We can’t expect every app maker to be proficient in design and creating something interesting, unique, and useful. MD saves the average app developer from making a really really terrible app. Yes, you still have to understand the design philosophy, the guidelines, the patterns. But it’s easier to use a set of components Google has made for you and copy patterns that occur in the MD-complaint apps.

          Disclaimer: I work at the GOOG.

          1. 8

            As a backend developer that has had to take on the lead on a few front end projects, this is a massive win. You can simply follow material design spec and get solving problems, then when someone queries why you have done something or wants something changed, you can just quote the material spec and get on with solving real problems.

            1. 7

              “real problems”

              1. 3

                and get on with solving real problems.

                I think if the application in question is small enough, then this might hold true; however once the project gains any significant complexity or scope then I’d say having a backend developer work on UI might cause a few ‘real problems’ of its own ;)

                1. 3

                  This an example of the kind of conclusion you don’t want to jump to. Material Design may be a good stand-in, but it is ultimately a one-size-fits-all solution to a problem (yes, a real one 😉) that is inherently case-by-case. It helps developers speed through UI design; it does not solve UI design. As much as Google may want you to believe that convenient untruth.