DEV Community: Arnav Mahajan

Microsoft Edge 79: What's new in the Chromium-based Edge?

Arnav Mahajan — Tue, 21 Jan 2020 06:47:53 +0000

Microsoft rolled out the latest version of its Edge browser, Edge 79, on January 15, 2020. This update, codenamed ‘Project Anaheim’, is a landmark shift for Microsoft, from the EdgeHTML engine to the Chromium engine.

Switching to Chromium puts Microsoft Edge on par with Google Chrome in terms of functionality, so user adoption and market share are expected to increase. Users who switch to or update the Edge browser are going to expect seamless, bug-free experiences on every website they access. Web developers need to test their websites for compatibility on Edge 79—among other things.

BrowserStack has partnered with Microsoft to give you unlimited access to Edge for Live testing. If you want to run automated tests,you can leverage BrowserStack Automate to run all your Selenium test cases on the Edge browser—on multiple devices—at the same time.

So why has Microsoft decided to switch to Chromium?

Microsoft has stated multiple reasons for making the switch from EdgeHTML to Chromium:

Greater reach: Microsoft can now leverage Chromium’s cross-platform technology—and make Edge available to all supported versions of Windows and other desktop platforms like macOS.
Better alignment: This will help both Microsoft and Edge align better with web standards—and other Chromium-based browsers.
Fewer bugs: Due to Chrome’s immense popularity, some web developers simply chose not to validate websites on the EdgeHTML codebase. This created occasional compatibility issues for Edge users.
Faster releases: Because EdgeHTML shipped on the same schedule as the Windows operating system, Microsoft’s ability to update the Edge browser was slowed down. This, in turn, caused platform fragmentation and exposed compatibility gaps.
Increased OS contribution: By switching to the Chromium project, Microsoft can contribute new capabilities to the Chromium open source project, for the benefit of all browsers, users and developers. This will, ultimately, help other browsers support Windows capabilities (like touch and ARM processors) better.
Partnering opportunities: This switch will give Microsoft a ‘welcome opportunity’ to partner with the global Chromium community in terms of battery life, touch, accessibility, security, and other areas of mutual interest.
Collaboration with Google: Microsoft intends to work directly with Google to improve the Chromium engine.

How does this benefit my end-user?

Along with upgraded performance, support for the latest rendering capabilities, powerful developer tools, and best-in-class compatibility with extensions, this new update to the Microsoft Edge browser gives users (among other benefits):

New privacy-enhancing features like tracking prevention, which is ‘On’ by default
‘Collections’, to allow users to easily collect and organize web content—and export into Word/Excel files. This will ultimately help users with content creation or decision-making
A new ‘InPrivate’ mode across the entire web experience. This means online searches and browsers will not be attributed to the user
‘Smartscreen and tracking prevention’ to prevent users from phishing schemes, malicious software, and malware like cryptojacking
Keyboard shortcuts to mute tabs on Mac devices
Dark themes for the search box, Microsoft news feeds and other top websites
Bug fixes for UI/UX issues

Why is this update so crucial to test?

The new Edge 79 is new and uncharted territory. There are several new factors at play—the Chromium project, the V8 JavaScript engine, and the Blink rendering engine. This version is completely different and utterly unrelated to any existing version of Microsoft Edge.

Wait, what’s a browser engine?

A ‘browser engine’, to put it simply, takes in HTML code and puts out a visual representation of the code.

When you ask your browser to pull up a website, here’s what happens: The browser requests data from the webserver. It then uses a browser engine to:

1. Process the HTML data (received from the webserver),

2. Calculate graphical coordinates,

3. Display it visually.

Apart from rendering and layout, the browser engine even handles security policy implementations, data submissions and the like. Among others, the most popular browser engines in use today include:

Blink, used by Google Chrome
Gecko, used by Mozilla Firefox
WebKit, used by Apple’s Safari
Trident, used by Internet Explorer

Does the browser engine handle JavaScript as well?

No. Browser engines only interpret HTML and CSS code. You will require a separate JavaScript engine to compile any JavaScript code for your browser.

Some notable JavaScript engines include:

V8, used to power Google Chrome
Spidermonkey, used by Mozilla Firefox
JavaScript Core, a.k.a Nitro, used by Apple’s Safari
Chakra, used by older Microsoft Edge versions

So what does Microsoft Edge use?

Microsoft, in true maverick fashion, built its Edge browser with its own EdgeHTML browser engine and Chakra JavaScript Engine. With the Edge 79 release, Microsoft is switching to Blink browser engine with V8 JavaScript engine.

Both Blink and V8 are developed under Chromium—an open-source project with an open-source web browser of the same name. Chromium—the open-source browser—is used by Google for its own Chrome browser. Now, Microsoft Edge will do the same.

Does this mean Edge will become the same as Chrome?

No. They’ll become similar in terms of underlying rendering performance and OS compatibility‚ but to an end-user, the experience will remain markedly different. This is to reflect the vendors' (Google's and Microsoft's) own development and design philosophies.

"Despite the same underlying (and open-source) browser engine, the end-user experience turns out to be very different on Chrome and UC Browser. This is because Chrome focuses on delivering performance and integrating with Google’s ecosystem. On the other hand, UC Browser focuses on efficiency through page compression and lower data consumption."

(Source: Why is cross-browser compatibility an issue in 2020)

Sharing the same underlying browser (Chromium) won’t change what Google and Microsoft decide to deliver through their proprietary browsers. Google’s Chrome will continue to favor performance and ease-of-integration with the rest of Google’s ecosystem. And with the switch to Chromium, Microsoft Edge will become more agile.

But whether it can catch up to Chrome’s market share remains to be seen.

To automate your Selenium test scripts to run on Edge 79 (in different devices), try BrowserStack Automate. To test your website interactively on a real device, try BrowserStack Live.

Recommended reading:

Resources

Testing for Fragmentation: Why do you need cross-browser testing for compatibility?

Arnav Mahajan — Mon, 06 Jan 2020 06:33:54 +0000

It takes a look at the market data on devices, platforms, browsers, etc. in use today, how this diversity comes into play during software development and testing—and what 2 million+ developers on BrowserStack do to account for it.

In this post, we look at browser internals, the differences among browsers, and the need for cross-browser testing.

“Has anyone spent several hours to get the UI of their application render correctly in all browsers? How do you tackle the frustration when simple styles tend to work in one browser but not others… and by the end of the day you invent a hack to handle it (in some cases that too does not happen), only after wasting your time?”

That was posted on Stack Overflow 11 years ago. And it hasn't become less tedious with time. Cross-browser testing still is the bane of every front-end developer and QA engineer on the planet.

The reason is browser fragmentation, and the only way to cope is by testing for cross-browser compatibility.

Why is browser compatibility an issue in 2020...

...despite W3C’s homogenizing open standards? Or despite the fact that most of the browsers have adopted Chromium/Blink as their go-to browser engine?

The answer is in the question itself: those standards are open to interpretation.

Browsers with the largest market shares are developed by different vendors. Each of these vendors have different design and development philosophies. This influences how they go about adding features, implementing support for new web technologies, and ultimately, the end-user experience of browsers.

Consider this: Despite the same underlying (and open-source) browser engine, the end-user experience turns out to be very different on Chrome and UC Browser. This is because Chrome focuses on delivering performance and integrating with Google’s ecosystem. On the other hand, UC Browser focuses on efficiency through page compression and lower data consumption.

Even the open-source browser projects are not afraid to “break things to make things.”

“Chromium’s mission is to advance the web, and in some cases, we find it beneficial to make a breaking change in order to do that.”

—Blink principles of web compatibility

For the average web developer, that one ‘breaking change’ could mean hours of debugging. You may decide not to use a new, radical browser tech in your website UI, but you will have to account for those changes while developing anyway.

For there are layers to a browser, and each of them affects the Quality of Experience (QoE) you deliver to the end-user. Let’s take a look:

Browser engine: Not to be confused with JavaScript engine (which is another core component), the browser engine takes in HTML, reads and renders it. Blink, Gecko, and WebKit are examples of browser engines. While open-source, these engines are different in their operation—even the operating systems they support. iOS, for instance, will only run WebKit browsers. So Chrome on Android and Chrome on iOS are going to be different at the very core.
Features: Vendors often add unique features to their browsers. Consider Apple’s Safari, which has Intelligent Tracking Prevention. It’s a machine-learning algorithm that understands the difference between first-and-third party cookies. Based on the cookies’ purpose [for instance, saving session details vs cross-site tracking for ad targeting purposes], ITP deletes them at various intervals from users’ devices. Even today, ITP continues to trouble online publishers who monetise their site content through behaviourally-targeted ads.
Support for popular web technology: Which web technology to support + when and how best to implement it—these decisions are made by popular opinion within the browser’s contributor community.
Update frequency: The speed with which contributing engineers release new features or security patches is different for each browser. Chrome gets updated every 6-8 weeks; Safari, once or twice a year. So if two or more browsers were to pick up ‘adding support for resolution feature’, it may take a while to be universally available.

Okay. Browsers are different. Why should I care?

Now, individually, the differences are minuscule and unlikely to affect a large percentage of your site’s traffic. But your site experience depends on how well you accounted for all the differences in browser layers. The probability of an unexpected UI bug is high.

The more you scale/expand your reach to new markets, the larger will be the impact of unexpected UI breaks in production. And this affects not just the bottom line, but the audience sentiment as well.

A website/web app has to work flawlessly for its audience regardless of the browser they are on. Lack of browser compatibility can have serious consequences, as was the case with:

Safari ITP impacted the retention of the Adobe Experience Cloud’s opt-out cookie. Apple automatically deleted the cookie that was set to prevent reporting on data, effectively opting the user back into tracking.
Bootstrap, a ground-breaking front-end development framework that saves countless hours of developers’ time, had to create a whole wall of outstanding browser bugs; in the hopes that browser vendors will pick up and resolve these issues in the near future.
A simple November 2019 Chrome update, supposed to make the browser become more resource-efficient, ended up wreaking havoc—especially for those running Chrome on a Windows Server (in an enterprise network setup).

“Employees are being left gawping at blank screens as Chrome suspends their browser throughout the day. According to system administrators speaking to ZDNet, hundreds and thousands of employees couldn't use Chrome to access the internet following the update.”

Outside of your dev environment, not everyone has caught on to the latest versions of Chrome and macOS. Plenty of users are on browsers other than Chrome—or versions of popular browsers older than the latest releases. You can chalk it up to familiarity and/or resistance to change (along with other reasons).

There’s only one way to minimize browser errors: by testing continuously for cross-browser compatibility.

Continuous testing for cross-browser compatibility

It’s definitely not enough to test on whichever browser you’re developing on and release it into the wild. To deliver quality at speed, you have to test smarter. And to do this, you’ll need:

A list of relevant browsers which will give you over 80% coverage in the market(s) of your choice—updated at regular intervals.
Thorough risk analysis to figure out the features most likely to break, and on which browsers and devices. This post by Hylke de Jong, an Automation Testing Engineer at Wehkamp.nl, details why you should be testing on devices with high risk—even if they aren’t used by a significant percentage of your traffic.
A solid delivery pipeline that lets your engineers continuously test and debug every unit, build, and end-to-end user-flow across each relevant browser/device.

Remember this: Cross-browser compatibility isn’t about how many people can enjoy the entire site/app experience. It’s about minimizing the number of people who can’t. For those who have a reputation to maintain, the stakes are even higher. For them, cross-browser compatibility becomes a matter of delivering quality, consistently.

One of them is Nicolás Bevacqua, a JS consultant and Blink contributor. He states that he cares about cross-browser compatibility because:

“..the fact that people were seldom using anything other than Chrome (to access my blog) gave me a good cover story for not pouring any effort into resolving long-standing (albeit minor) CSS rendering issues in Firefox and Safari. However, 20% of visitors were getting a less than ideal experience, which ultimately wasn’t something I could scoff at.

It didn’t speak well of me to have these blatant rendering bugs lying around in my blog when visited through popular non-Chrome browsers. It wasn’t tidy.”

Recommended reading:

Testing for Fragmentation: A risk-based approach for targeted, effective testing

Arnav Mahajan — Mon, 06 Jan 2020 06:19:36 +0000

Whenever the subject of fragmentation comes up in the context of mobile app testing, the focus is mainly on knowing what to test, and where. While the former pivots on knowing your app, its functionality, and expected behavior, the latter revolves around market research and insights about the devices your customers commonly use. But exhaustively testing every part of your app on every possible device is not exactly feasible. It would require tremendous effort and time. But there is a workaround for such a situation - a risk-based approach to testing.

Consider the right parameters
Risk-based testing is a method in which you focus on, and give priority to, the parts of your app and/or the devices that have the highest risk associated with them. Generally, people tend to think that this applies to the most used parts of your app and the most used devices. While this is not entirely wrong, there are more nuances to consider. For starters, how do we quantify risk? The generic formula to calculate risk is:

Risk = Probability * Impact

The formula is quite straightforward. The amount of risk is based on two variables. Probability is basically how likely it is that something is going to happen. The second variable is impact, or how bad is it when something breaks. Let’s look at an example to see how this works out in practice.

Screen resolution is a good metric to differentiate mobile devices by. In the case of iPhones, most are rather similar in size and resolution. But the iPhone SE stands out, with its modest 640 x 1136 pixels size. It’s an older phone and so general usage numbers are usually low. When only going by that parameter, the iPhone SE isn’t a highly relevant target device for our testing.

However, it is important to factor in the phone’s fairly low screen resolution; especially the low 640 pixels width. This is one of the main reasons why most UI-related aspects break regularly on this device. There simply isn’t enough room to display everything, causing buttons or elements to disappear or overlap, thus limiting user interaction with those key elements.

So, the probability of things breaking on the iPhone SE is quite high. The impact, of course, depends on what functionalities are being rendered unusable. Suppose two buttons overlap, and both usually can’t be tapped, it is a serious issue. The iPhone SE, in this case, has a high risk of potential bugs. This makes the iPhone SE an interesting, and important, device to run tests on.

Think beyond devices
When only looking at devices, we tend to make generalized assumptions - that all functionality is important, and every test should be run on all of them. But assumptions are detrimental, especially when the context is (containing) risk. To figure out which functionality within your app should receive more attention, the risk-based approach outlined above can be used.

For instance, we run a webshop and one of the most important parts of our customer journey is the checkout. The reason is simple: if customers can’t pay, we won’t make any money - there’s your high impact. Probability is an interesting part of the equation in this case; ideally, the probability of our checkout page glitching is low given its importance and the focus it gets. However, we built a hybrid app, meaning roughly 90% is native iOS, but the rest uses our mobile website in a WebView. The checkout is part of this 10%. This means that we suddenly have three more variables to take into account - native iOS, WebView, and the mobile website; all with their own set of quirks and focus areas. So the probability of checkout-related issues just went up, making the checkout a high-risk area of our app, and as such, a very interesting target for testing.

This works both ways. Parts with lower risk can either be skipped or put in a different (lower priority) test suite.

This also really helps with insight into why you do certain things. People outside of quality assurance are quick to point towards areas they think are important and should be tested. They mean well, but many times, this is based on gut feeling. With the risk formula, you can logically explain your approach. More importantly, you can recognize when there is negligible added value in additional testing.

Fragmentation in release versions
In general, people think that fragmentation is only on the device/browser/OS level, but it can also happen between different builds of the same app. Not all users update automatically. You could force them to update, but that’s a rather heavy measure to take. Customers generally don’t like being forced to do something. A forced update will immediately reflect in your App Store/Play store reviews; usually not in a good way.

This implies that, at any given point in time, you might have multiple versions of your app running in production. All with their own set of features, functionalities, and bug (fixes). This adds an extra layer of complexity to the already complex puzzle that is fragmentation testing.

This is also where monitoring comes in. Sure, you can run your tests in production, but then you’re still constrained by the devices you choose to run your tests on. Monitoring gives you a test pool with unlimited devices and OS versions. Obviously, I can't stress enough on the importance of having a robust monitoring and altering process in place, to detect major issues in time. Though it is a comprehensive task, once set up correctly, it gives you access to a very interesting set of data.

For instance, we can see which build has a high crash rate. But more importantly, it also gives you more detailed information about the device, OS, app version and which class caused the crash. That last part is especially crucial as it brings an immediate focus on the potential source of a bug. You can also extrapolate trends from this information. For instance, is there a device that is over-represented in the crash data or is there a build that stands out with more crashes than others? This is very valuable information to adapt your test strategy and approach.

Use crash data as valuable test input
This idea of testing based on risk is a good way of making informed decisions for device selection and functionality to test. If you supplement this selection with the crash data of your app, what you get is a remarkably targeted, efficient test suite.

It’s important to understand that this is an extension of your test strategy. Of course, you start with testing the most used devices and most used/important functionality. But once you’ve covered that, it’s a really nice addition that can give you a lot of pointers for high-risk parts of your app.

And this also works the other way around. If there are parts of the app or devices that never show failed tests or crashes, remove them from the test suite. A lot of testers freak out at the thought, but it’s the most sensible thing to do. A test that keeps running green over and over and over again looks nice in the dashboards, but overall it doesn’t add much value. And since we’ve almost always short on time, this is one shortcut that is definitely worth taking.

Testing for Fragmentation: Is your UX tested for Global Compatibility?

Arnav Mahajan — Thu, 12 Dec 2019 06:14:14 +0000

“Testing for Fragmentation” is a blog series. It takes a look at the market data on devices, platforms, browsers, etc. in use today, how this diversity comes into play during software development and testing—and what 2 million+ developers on BrowserStack do to account for it.

In this post, we look at how Fragmentation varies across the globe and key statistics you should keep in mind if you have a presence in these markets.

The growth mantra of online businesses is scale—reach more users, fast. However, as you scale across countries, it’s important to ensure that your app/website is compatible with your users’ devices and browsers.

Compatibility is to online businesses what distribution is to brick and mortar ones. You might have the best product in the world, but it counts for nothing if your customers don’t have the experience you designed for them.

For instance, being compatible with the top 20 devices will help you cover 70% of the US audience. In India, not only will the devices be different, the coverage provided will be less than 35%. Similarly, if your mobile website doesn’t load properly in Opera browser, you would have ignored almost half of the Nigerian market!

Clearly, what works in one market won’t necessarily work for another. So, in this blog post, we will outline country-specific fragmentation nuances that you need to consider if you have a presence in these markets. Or plan to, in the future. We have tried to cover at least one country in each continent.

After reading this piece, you should know:

How the fragmentation landscape changes in each country
What the are factors that lead to this
Key browsers to test on
Major device manufacturers dominant in each country

United States

A strong market share of Apple devices in the US makes testing on iPhones and iPads (both new and old) a no-brainer. It’s a common myth that iPhones are not affected by fragmentation. However, if you do a risk-based analysis, testing on older iPhones is critical. They have significant traffic (over 40% of iOS traffic) and the probability of UI breaks is higher.

Another set of devices to consider is tablets. The market share of tablets, in terms of traffic, is over 5%. Testing on the most popular Apple and Samsung tablets should be enough to cover a decent majority.

Things get more interesting when we come to desktops. For accessing the internet, the usage of desktops in the US is still more than mobile. The problem it creates is that the browser market is more fragmented.

You can safely release your websites only if you have tested them extensively across Edge, Firefox, and IE apart from the usual Chrome and Safari. This is mainly because each one of them has over 5% traffic coming through them.

Germany

The usage pattern of devices and browsers doesn’t vary much across western Europe. While device fragmentation isn’t as high as Asia, a stronger market presence of Android devices makes things difficult for testers. The three leaders in Android—Samsung, Huawei, and One Plus—run their own custom OSes, thereby increasing the combinations to test on.

For desktop browsers, testing on Chrome, Firefox and Safari is a must. However, IE and Edge have over 5% traffic each and testing on these two browsers can optimize the experience for a lot of your users.

Tablets, too, perform well in Germany and contribute to around 4% of the traffic. Most of this is from Apple and Samsung tablets, so adding them to your test suite will improve coverage.

India

Very few markets are as dynamic and as complex as India; as expected, fragmentation here is colossal. While the new devices and browsers are allowing millions of people to access the internet, testing across these devices becomes a nightmare. The Indian market is so fragmented that testing on the top 20 devices accounts for less than one-third of the user base.

Besides new and upcoming brands and models, there are established names like Samsung J series, Xiaomi Redmi series, as well as the multitude of Oppo and Vivo devices to test on. Android has a staggering 93% market share in India, and a new OS for affordable phones, KaiOS, beats iOS in terms of the traffic.

The same holds true for browsers. If your traffic comes from India, UC Browser and Opera must feature in your test suite. They account for over one-fourth of the traffic in mobile browsers.

A lot of first-time internet users in India leapfrogged desktops and are using mobile phones directly. Given this, and the fact that over 75% of traffic comes from phones in India, testing on mobile browsers is as important as desktop browsers.

Australia

The fragmentation landscape in Australia is very similar to that in the US. A large bulk of the traffic comes from Apple and Samsung Galaxy devices, with Apple having around 57% market share.

In terms of browsers, the must-test browsers are Chrome, Safari, Firefox, IE and Edge, each bringing more than 5% of the total traffic.

The Australian market has over 8% traffic from tablets, one of the highest in the world. If you have traffic from this region, testing on tablets is strongly recommended.

Nigeria

Much like Asia, the African continent is also a highly fragmented market. Mobile forms more than 70% share of the traffic and Android devices own 76% of the market. Interestingly, Windows phones have a larger market share in Nigeria than any other country. However, in the larger picture, it is only about 1% of the traffic.

Here, too, testing on the top 20 devices will give you less than 40% coverage. In addition, you will have to test on unique phones such as the Tecno Spark and Infinix Hot series of devices.

The most interesting behavior is exhibited in terms of mobile browsers. In Nigeria, Opera leads the market, surpassing even Chrome and Safari. This is primarily because Opera helps users in saving data costs. Chrome is catching up fast, but Opera still leads the market.

For desktop browsers, Chrome, Safari, and Firefox lead traffic.

Brazil

The extent of fragmentation in the Brazilian market is high, thanks to a higher market share of Android devices (around 75%). Here, too, the devices you need to test on are different from the other parts of the world.

Smartphone penetration is less than 50% in Brazil and new users prefer affordable smartphones. Therefore, Samsung J series and Motorola G series devices rule the market, along with a few old-generation iPhones.

Interestingly, over 70% of internet traffic in Brazil comes from desktops. While this is declining, it will be a while before the scales tip. Testing for desktop browsers thoroughly is a must for this market. Even though Chrome owns more than 80% of this space, testing on Firefox, IE, Opera, and Safari shouldn’t be missed.

Russia

Russia is also a highly fragmented market with the top 20 devices giving just over 45% coverage. The key devices you need to test on are older iPhones, Samsung J and A series, and Xiaomi Redmi series devices.

In terms of browsers, Yandex is the 2nd most popular browser in Russia and testing on it is a must if you have Russian customers. Opera also garners over 5% of Russian traffic and should ideally be a part of the test suite.

Being prepared

Every country has its own set of differences in terms of the devices or browsers that people use to access the internet. The best way to prepare is to be cognizant of the differences that exist and account for them while building your test suite.

These differences might seem daunting at first, but looking at them together for your entire traffic will make decisions much easier. You can never test on all devices, but by knowing the key trends across the globe, you can minimize a huge portion of risk by testing for those variables.

Recommended reading:

Open Source Spotlight: Sulu with Daniel Rotter

Arnav Mahajan — Tue, 03 Dec 2019 07:48:44 +0000

Featured in this edition of Spotlight is Daniel Rotter (a.k.a. danrot), creator of Sulu—the Symfony CMS. Sulu helps content teams deliver complex sites and great user experiences.

Daniel is a former lecturer who now lives in Altach, Austria. He is an active member of the local developer community, and organizes local meetups and conferences.

What seeded the idea for Sulu?

While using Symfony for our projects at work, we realized there was no CMS completely based on the Symfony framework. This complete lack of options gave us the assurance that a potential market existed.

We decided to make the new CMS easy for anyone to use and provide clear documentation.

Our years of experience from developing client projects at MASSIVE ART gave us a head start. Today, we can say that Sulu is a success—proven by the many developers using Sulu worldwide.

What do you have in mind for the short-term and long-term future of Sulu?

We released Sulu 2.0 very recently. We switched our complete frontend stack of administration from jQuery, AuraJS and Backbone to a modern React application.

We put a lot of effort into this, and now we have a full-blown data management solution which isn't restricted to CMS. Backend developers can build custom entities with business logic, and can configure afterwards how the administration interface should look like on the server side.

That's based on a lesson we learnt from the Sulu 1.x series, which was that backend developers don't like to touch any frontend code at all. This meant users didn't get the most out of their Sulu installations, because they tried to avoid creating their own entities (allowing them to be edited meant they had to write JavaScript code).

In the short-term, we are trying to fix bugs that might have appeared in Sulu 2.0, although it already feels stable because we used it in quite a few projects internally before release. Then, we will add a few more content-related features, like allowing users to nest content blocks in forms.

Long-term, we already have a few plans on what we want to do in the 3.0 release, which will be mainly about server-side, since we've put a lot of effort in the frontend part in Sulu 2.0. We think it makes sense—for a project of our size—to concentrate on only one end for each major release.

In 3.0, we want to improve a lot of our content storage mechanisms, and try to apply more Domain Driven Design principles in the general architecture of our server-side code.

How would you describe your problem-solving process?

Usually, I try to get a good understanding of the problem and split it into smaller sub-problems.

These sub-problems are easier to fix. Once I have solved one of them, I will commit my code, so I can start with a fresh mind again. This way, I know that everything I have done so far works as intended, and I don't have to keep track of all the changes that are not committed yet.

Having a lot of uncommitted changes in git is something that clutters my mind, which might be related to me being a minimalist (which is probably why I use software like ArchLinux and Neovim).

What is the one thing new developers need to learn?

In my opinion, the most important thing is to not only know the different concepts, but to know when it's the best time to apply them.

At Sulu, we always have to distinguish between our core product and client projects with different priorities. In client projects, it is more important to meet deadline and budget criteria, while on our product it is more important to deliver quality (otherwise it will cause you headaches for years).

For our product, it is also very important to have a lot of extension points, because people want to integrate their own functionality without touching your code. This is not a real requirement in a client project, since you are in full control of your entire code anyway. You usually don't need your code to be extensible, because if needed you can just change the code itself. This will result in easier understanding of the code.

What were some obstacles you faced while coding for Sulu?

I think developing Sulu 2.0 was one of the biggest obstacles I've faced so far. The problem was that we had no choice but to replace the full frontend stack.

In a client project, I would have decided to start by using the new framework—in our case, React—in just a few places, and try to convert other parts over time. However, this does not work for an open source project. If we had released a new version of our CMS, where you would need to use two different frontend stacks to extend anything, then I'm sure this would be a very negative argument in every technical evaluation.

So, we decided to go for the full rewrite, and of course it took us longer than we anticipated. However, I am really happy with the final result, and I am glad that we chose that path.

How important is testing for your project? What tools do you use to test?

Testing has a very high priority in our project.

We use all kind of automated testing tools, like PHPUnit and Jest for all kinds of automated tests. We use static code analyzers like PHPStan and Flow to avoid errors early. We use linters like ESLint to catch a lot of errors that are easily overseen by a human in a code review.

This results in shorter review cycles, because a lot of errors, namely code smells, are already solved before a reviewer gets to look at the code. And shorter review cycles also result in a shorter time-to-market.

Since we do a lot of JavaScript development, it is also important to test our application on different browsers. BrowserStack is our tool of choice here, because it is a lot easier than handling loads of virtual machines containing the browsers you need on your own.

What do you think is the best way for developers to network? What social media networks do you frequent?

My absolute favourite way to network is through real-world events (meet-ups and conferences). It is a lot nicer to get in contact with people in person, rather than over the internet. Nevertheless, I still get my quota of technical news from the people I follow on Twitter. It feels to me like most developers are active on Twitter, but not so much on Facebook, LinkedIn, or the like.

What do you wish more people would ask you about?

That's an interesting question. I think I would love to talk to more people about our Sulu 2.0 release, because that's something I am really excited about. Otherwise, I don't care a lot about what people ask me, I am glad if I can be of any help to anybody :-)

What are your productivity hacks?

Keep it minimal! I love doing stuff on the console, including using Neovim. I feel a lot faster on the console than clicking through dialogs.

Also, splitting a problem into smaller problems is a technique I love, because it is easier to get into my desirable flow state where I am undistracted.

Check out More like this on Browserstack's OpenSource Spotlight.

What is Fragmentation?

Arnav Mahajan — Wed, 13 Nov 2019 13:28:50 +0000

Now that you've seen the extent of fragmentation in devices, platforms, browsers, and screen resolutions, learn how to take them into account while creating your own cross-device test strategy.

Recommended reading:

Testing for Fragmentation: Understanding Browser, OS and Device Fragmentation

Arnav Mahajan — Wed, 30 Oct 2019 08:03:25 +0000

In this post, we’ll deconstruct fragmentation as it exists, and what that means for application quality.

More than 4 billion people access the web through combinations of:

9000+ distinct devices, shipped with
21 different operating systems (vendor + version), along with
8 major browser engines that power hundreds of browsers.
Combined, they make at least 63,000 possible browser-platform-device combinations. And those are the ones we know of, at this time.

That’s the scale of fragmentation.

What exactly is fragmentation, really?
The sum total of differences—between devices, platforms, browsers, variables like network providers and more.

Why is fragmentation a problem?
Because the differences between devices, platforms, browsers, and more cannot be abstracted by a single, universally interoperable framework.

So when it comes to software development:

“Fragmentation is the inability to "write once and run anywhere”.

—Damith C. Rajapakse
(Prof. of Software Engineering, National University of Singapore)
Since your website or app can’t have universal interoperability on every possible combination of device, operating system, and browser in the market, you have to settle for its watered-down counterpart, compatibility.

To achieve compatibility, you have to test every bit of code across browsers, platforms, and devices. Or you have to keep your developers busy with an endless barrage of cross-browser and cross-platform bugs that creep into the builds (or worse, production).

So we do compatibility testing?

Early and continuously, because the market evolves fast. The browsers, platforms, and devices your application works on today will lose their market share with each new:

Platform update: macOS pushes platform updates once a year. Windows 10 editions hit the market sporadically.
Browser update: Chrome releases major browser updates every six weeks or so.
Device launch: Number of devices in the market grows by 20%, every year. Some of them will be used by your customers to access your site.
Which combinations do I test on?

For an existing website or app, you’ll start with analytics. But that’ll give you an implicitly biased answer. Your website/app only gets traffic from devices/platforms and browsers it supports in the first place.

To figure out the variety of combinations of devices/platforms and browsers you must support (to keep the lights on at work, or expand your reach).

“Since it is the diversity that drives fragmentation, a closer look at diversity may provide us with clues as to how to deal with fragmentation.”

—Damith C. Rajapakse
In that spirit, here is a look at the depth of fragmentation—in devices, platforms, browsers, and screen resolutions. These are the first four components you’ll account for during your development and testing.

Device type

In 2019, global web traffic is split cleanly between mobile, desktop, and tablet.

No surprises there. But even if your website’s (or app’s) traffic patterns don’t match this split, the graph is still relevant. That’s because it quantifies a behavioral shift: The Mobile Tipping Point.

“The Mobile Tipping Point is the point at which consumers spend longer online per day on their mobiles than all other devices combined.”
An average person on the internet spends about ~7 hours online—split equally between desktop and mobile. And so you have to test on both desktop and mobile.

Is that enough? Not really. You see, there’s a multiplier effect. Fragmentation becomes a bigger problem not just with every new mobile or desktop device—but also with the operating system they come equipped with. And fragmentation within operating systems is staggering.

Operating system (OS)

We would split the operating system fragmentation by device type. But in web development, desktop OS will be of concern when you’re looking at how many browsers a desktop platform supports. So let’s jump directly to the bigger problem, that of mobile OS fragmentation.

To understand this, we’ll have to start with mobile device manufacturers.

There are 6 mobile device vendors with a global market share of ~77%.

This graph will look very different for your traffic, or when filtered by countries. However, in most countries, you’ll notice a common thread: Android-powered smartphones are gaining the upper hand over Apple iPhones.

At the time of writing this, 40% of all web traffic comes from devices powered by Android.

That’s 1.7 billion online users across the world. That wouldn't be a huge deal, if the Android fragmentation weren't a triple-layered problem:

There are 6 different stock Android (the core open-source platform) versions in the market:

There are 6 different stock Android (the core open-source platform) versions in the market:

Stock Android—all 6 versions of it—only powers Google Pixel (and some LG) smartphones. Most device manufacturers create custom platforms out of stock Android for their devices.

At the moment, some of the more recognizable Android-based operating systems are:

One UI by Samsung (for Galaxy series)
OxygenOS by One Plus
MIUI by Xiaomi (a popular smartphone manufacturer in APAC)
Huawei EMUI

Manufacturers who power their devices with Android-based operating systems don’t update them consistently.

So at any given point in time, an Android app that wants to be globally accessible has to maintain compatibility with:

4-5 different versions of core Android, along with
8-10 custom-Android implementations.

Compared to iOS, where your app has to be compatible with 2 major iOS versions in a given year, accounting for fragmentation on Android is difficult.

The two factors—device and operating systems—are important when we speak of native applications. For the web, you have to throw browsers into the mix.

Browser

There are 6 dominant browser families in the world.

The W3C (World Wide Web Consortium) laid out a set of standards in an attempt to ‘homogenize’ how browsers render pages. So why does your web app not render the same across them all?

They have different rendering engines. Safari and Opera are built on WebKit, but Chrome uses Blink, Firefox uses Gecko, and so on. These affect what your web pages look like on the client-side (to the users).
Browser vendors don’t really implement W3C standards in the exact same way. Imagine a race: W3C laid out the track and set the rules, but browsers get to the finish line by finding their own shortcuts.

And so it falls on developers to test across browsers. But nailing the right ones is difficult. Consider the chart below:

There are two key takeaways from this data:

Each browser family has multiple versions in the market, and these versions have their own (significant) market shares. Just look at Chrome and Safari.
A browser version will behave differently on desktop and mobile.
For instance:

Chrome 76 on desktop vs Android. HTTP Live Streaming (HLS) works on all versions of Chrome for Android, but not on Chrome for desktop.
Any version of Safari on macOS vs iOS. PNG favicons work perfectly on all versions of Safari on macOS, but not on any version of Safari for iOS. Now that you have context on browsers, platforms, and device types, here’s the final piece of the ideal coverage puzzle, particularly for web developers across the world.

Screen resolution
Here are the most popular screen resolutions across the world:

To cover 80% of the global online traffic, you will need to test on 10 different screen resolutions.

Takeaway
For 70-80% global coverage, your website/app needs to be work across:

3 device types—mobile, desktop, and tablet
2 iOS versions
5 stock Android versions
8-10 custom implementations of stock Android versions
6 browser families
Popular browser versions within each browser family
10 screen resolutions
If you multiply them, and leave room for healthy skepticism (not all browsers work on all operating systems), the number of possible combinations racks up to—pretty discouraging.

And testing on them all will give you 80% global coverage for a brief few weeks.

As you’re reading this, the market is evolving. Within the month, Chrome 77’s market share will increase. More Android smartphone manufacturers will have released platform updates and moved to a Pie-based implementation. iOS 13 jumped from 5% to 50% market share while we were writing this post.

The only way to keep up with this market is through early, continuous compatibility testing.

Recommended reading:

References:

github.com/damithc, Damith C. Rajapakse, professor of Software Engineering at National University of Singapore.
blog.globalwebindex.com, Device landscape.
www.thenextweb.com, Android Phone brands ranked by update frequency.
Statcounter.com, Deviceatlas.com; Global device, platform, browser, and screen resolution data.
Statista.com, Number of users online in 2019.
CanIuse.com, Browser version market share.

This post was originally post on: https://www.browserstack.com/blog/testing-for-fragmentation-understanding-browser-and-device-fragmentation/