First chapter of the book "IBDD: In-browser Design Documentation Method"

    Since 2011, I started designing websites responsively, accounting for smartphone and tablets growing use by the web audience. Around 2014, I started preferring to design directly in-browser and by 2018, I have developed a method for design documentation of in-browser web design. By 2020, I had the chance of applying my method in collaboration for the redesign of a web shop, thinking of submitting an article to a web standards publication.

I was already graduating in computing and planning a masters in Software Enginnering, so I was expecting that after my article was published, my method to be further tested in design master tesis by someone else. Then came isolation, a HD loss and a change of plans; resulting that in 2022 I've decided to turn the article into a book about my method, while also working on my graduation monography on Software Engineering. Here’s the first draft of the first chapter of a book about my method that is on its way:

© copyright  — Alex Burroughs, 2018-2023

Chapter 1:  What is In-browser Design and why it matters.

Presents an overview of In-browser Design, explains its importance for Responsive Web Design, states the need for in-browser design documentation and advocates for the adoption of a method to allow its documentation.

In-browser Design? What is this?

    The evolution of web browsers and its advanced tools allowed that web designers started designing web pages while testing how changes would look on device’s screens. This way of creating and modifying web pages presented a step forward on web site development in comparison with the old way of designing web pages: after the wireframes* were aproved — sometimes this step is skiped, though not recomended, the designer started to apply a graphic style to the static content structure, utilizing graphic softwares, such as Adobe Illustrator, Photoshop or other similar program to present and aprove the page layout. When there are no more design changes to be made, then the web page is coded in html, css and javascript by a developer, which in some cases is also the designer. 

*wireframes are a skeleton of the web pages with the hierarchy of content structure. They can vary from rough sketchs to high-fidelity, rich in details page wireframes. Other design elements, such as decorativ graphics and colors are applied later.

With in-browser design, after some basic wireframes are sketched, any more detailed wireframe with content structure is already designed in-browser, that is, it is coded by the web designer in any source code software of his/her choice, and any chance is tested in the computer browser in real time. 

While this procedure is more dynamic and presents great advantage when designing for diverse screen formats, its major flaw is the lack of proper documentation of the design process. Design changes made directly to html/css code are efemeral and one can easily loose count of how many changes have been made before coming to a final version. The IBDD — In-Browser Design Documentation Method is a quick yet efficient way of keeping track of those changes, as well as of the problems they solve and of the design decisions for the solutions presented.

With responsive web design (RWD), the design layout must consider different devices formats and sizes, thus emphacizing the efficience of the in-browser design process. The application of  responsive web design principles to the web page can benefit considerably from adopting this method, when compared the traditional design approach.

RWD: Principles, mobile-first, advantages of in-browser design for responsive design

If, instead of two versions of a website, one for desktop, other for mobile, the site is designed and coded in a fluid manner that adapts to the format of any device, it gets easier to keep consistency between what the user access on mobile and what is viwed in a desktop browser at home.

Before responsive design became largely adopted, it was not unusual seeing mobile versions of sites on the web that were completely different from their desktop website. Besides that, maintainance gets a lot easier and much time is saved on keeping the website updated.

It all sounds wonderful, but on the other side, the design and development of a responsive websit is longer than designing a non-responsive one. Nevertheless, it does pay; for you will now have a website ready to be viewed from any already existing device format, and from the ones that are yet to come.

When designing a responsive website from scratch, some challenges are presented: you must keep content and design consistency, regardles of the size of the device through which your website is accessed. Content, be it text and images, or graphic elements, must fit within the small size of a smartphone, and yet look good when viewed in a large format.

Mobile-first is a general principle that applies well when designing for the responsive web: keep in mind that it’s easier to expand from a small container than shrinking everything and trying to make it fit within a small space once it has been desgned for desktop first. Think of downsizing from  a two-room, with a bathroom and kitchen, fully furnished apartment to a kitnet, when its inhabotants expect to find all their things in the same place when entering the new home. Now, compare it to the opposite situation, when realocating from the kitnet to the two-room. You may need some decorating touches for making the space not to look empty, but that’s way more sensible choosing this approach.

If you think mobile-first, you must prioritize what’s really essential for your website’s user t see. Content hierarchy becomes more important, since there´s less space above the fold. Recurring to the apartment analogy once more, when you live in a kitchnet, you must pocess a sense of what’s really important to keep in your life. Designing for mobile-first goes beyond the good practices of responsive web design, it helps the overall web design process as a whole, with an emphasis on website architecture and content hierachy.

I’ve been looking for a faster and more efficient way to design websites responbly. When I designed websites using a graphic software,ght after a few quick pencil or pen sketches on paper, around 2011, I had developed the work method of putting three main sizes side by side for a global view, starting from a vertical strip for mobile on the left side of the canvas, a vertical tablet format on the middle, and lastly, a desktop format on the right.

With any addition or layout change, I started from mobile and went on positioning elements, adapting it for larger formats. This works well for a few reviews, but as the website grows, with the design of internal pages and lots of adaptions to be made, even this method can become exhaustive and counterproductive.

Designing directly in-browser is more dynamic and I’ve been among the group that prefer to do so since 2014. Browsers like Firefox and Google Chrome present their own set of developer aid tools to help with this. Editing the code in your code editor of choice speeds up the process and previewing the changes in the web browser allow better better experimentation with intermediary sizes. Online tools like Am I Responsive and Responsinator can read from your web adress and display the website in the most popular device formats.

Additions and alterations are ephemeral, though, and it’s easy to loose track of how much has been done before coming to a final version of the site.

One thing that definitively made me abandon the traditional process of designing websites using a graphic software was that pages tend to look good on the layout, but get a bit static, in terms of events and transitions, since interaction is added only after the layout is concluded.

With in-browser design, interactions and transitions can be tested before the design is finished, thus graphic solutions are thought of together with interaction, resulting in a page whose behaviour is perceived to be more dynamic.

The advantage starts early on the design process: wireframing In-Browser

A good web design solution starts with wireframing. After a rough sketch was made, detailed wireframes can be designed in-browser. This allows testing the website’s navigation and gives the client or stakeholder a better feel of the behaviour of a website’s final version, which saves a lot of redesign.

It’s not uncommon that a client don’t clearly understands a wireframe and asks for changes later in the process, after seeing the graphic design layout. With in-browser design, you have a high-fidelity prototype, that is similar to webdesign end product, only missing the final raphic treatment and back-end programmiing.

Data can be added dinamically to the layout, thus design dapations can be made beforehand, taking this into account.

Must the designer know how to code? 

Many web designer today know how to code, and among those are the ones who design directly in-browser. While it’s a great advantage to the web designer being able to code, many times design tasks are done by a design team.

The documentation method presented here on this book allows that design decisions and tasks be done by two or more. Designers and developers can partner with design orientation and guidelines for in-browser alterations.

© copyright  — Alex Burroughs, 2018-2023