User/hanamemon/explorer spec #66
Conversation
|
LGTM. Most of my feedback was in the word-doc as the precursor to this :). Thank you. |
| ## Goals | ||
|
|
||
| 1. Primary goals include increasing the number of users who use enable DeviceMode and increase number of users who test more than 1 device. | ||
| 1. Improve satisfaction and efficiency in designing a website through easy access to and visibility of multiple viewports. |
There was a problem hiding this comment.
I would argue that this should be the primary goal. Increasing the number of users isn't a goal in itself, it's one possible measure of success.
|
|
||
| ### Add a new viewport | ||
|
|
||
| Users will be able to add a new device to the viewport by simply checking a box from the dropdown list of devices in the viewport toolbar. Once a device is added, it will appear either next to or underneath the existing viewport(s) with a toolbar on top of it. The devices will be re-centered to accommodate the new viewport. As more devices are added and the viewport fills up, the user will be able to vertically scroll down the viewport to look at all the devices. |
There was a problem hiding this comment.
What do you think about adding a way to scale the viewports down if there is not enough space?
Adding a vertical scrollbar to see other viewports is good, but it also means you can't see all of them at the same time which, I think, is the point of the feature.
When I make CSS changes to my webpage layout, if I can immediately see what it looks like on a wide and narrow viewport in real-time, without having to scroll down, or resize the page, then I'm way more productive.
So perhaps there could be an option to try to always fit the multi viewports on the screen, even if that means they need to be scaled down (so the webpage appears smaller than it normally is, but at least you have an overview of all viewports at once).
|
|
||
| ### Open DevTools against a new viewport | ||
|
|
||
| DevTools will remain the same, regardless of the number of devices in the viewport. As in the current version of DevTools the user will be able to choose the placement of DevTools on their screen and expand/shrink the DevTools window. |
There was a problem hiding this comment.
I think there needs to be a note about which viewport is DevTools targeting.
Indeed, depending on the screen size, a webpage may behave differently, have different JS code running, or even have different DOM elements.
Here are 2 examples:
-
If I add some JS code that sets a variable based on the window size like:
window.a = window.innerWidth > 1000 ? true : false;. In this case, if I have 2 viewports, one that's narrower than 1000px and the other one wider, then the value ofawill befalsein the first case andtruein the second. So if I use the Console panel in DevTools to log the value ofa, what should happen? Should the expression be evaluated in all viewports, and all results shown? Or should it be evaluated only in 1 viewport, and in which case, which one? -
If I have some CSS code that displays a pseudo-element depending on the window size, like
@media (min-width: 1000px) { body::before { content: "Large"; } }. In this case, if I have 2 viewports (one narrow, one wide), a pseudo-element will exist in one, and not in the other one. So what should be displayed in the Elements panel when I expand the<body>node? Should there be a way to see both states at the same time? Or just one state?
The above examples are arbitrary and simple, just to make the point, but these things do happen often in real websites and can be way more complicated.
I think DevTools should target just one viewport, to make things simpler. But then that also raises the question of how changes made in DevTools are replicated. If you start changing CSS in the Styles panel, should the change be mirrored in all other viewports? What about if you change the DOM (modifying an attribute, or adding a node), etc.
There are probably multiple steps that can be taken in achieving this, but the explainer should mention it.
There was a problem hiding this comment.
noted, thank you for the scenarios -- we will definitely be thinking about them as a team throughout this project!
There was a problem hiding this comment.
Sounds good. Because this can be potentially very complex, I would advise starting with DevTools being attached to only one viewport, i.e. the first one. Secondary viewports that get added after this would be synchronized as you explained, but would not be reachable with DevTools.
I think it is important to add a note about this to the explainer @hanamemon.
There was a problem hiding this comment.
I agree -- updating the explainer now to reflect this perspective.
| ## Sizing the Business Opportunity | ||
|
|
||
| Given that Device Mode is the second most used feature in DevTools users, such as professional developers and website testers, will continue to rely on Edge DevTools to streamline their processes. This feature will drive developers to Edge when they're specifically testing multiple screen sizes/devices/layouts. |
There was a problem hiding this comment.
I'm not sure this business opportunity should be in the explainer document. An explainer document's goal is to detail a user problem/opportunity and a solution for it. It is not meant to explain how it fits in our internal strategy as a team.
The explorer pod has completed the spec using Zoher's template and is looking for feedback and comments!