{"rowid": 26, "title": "Integrating Contrast Checks in Your Web Workflow", "contents": "It\u2019s nearly Christmas, which means you\u2019ll be sure to find an overload of festive red and green decorating everything in sight\u2014often in the ugliest ways possible. \n\nWhile I\u2019m not here to battle holiday tackiness in today\u2019s 24 ways, it might just be the perfect reminder to step back and consider how we can implement colour schemes in our websites and apps that are not only attractive, but also legible and accessible for folks with various types of visual disabilities.\n\n This simulated photo demonstrates how red and green Christmas baubles could appear to a person affected by protanopia-type colour blindness\u2014not as festive as you might think. Source: Derek Bruff\n\nI\u2019ve been fortunate to work with Simply Accessible to redesign not just their website, but their entire brand. Although the new site won\u2019t be launching until the new year, we\u2019re excited to let you peek under the tree and share a few treats as a case study into how we tackled colour accessibility in our project workflow. Don\u2019t worry\u2014we won\u2019t tell Santa!\n\nCreate a colour game plan\n\nA common misconception about accessibility is that meeting compliance requirements hinders creativity and beautiful design\u2014but we beg to differ. Unfortunately, like many company websites and internal projects, Simply Accessible has spent so much time helping others that they had not spent enough time helping themselves to show the world who they really are. This was the perfect opportunity for them to practise what they preached.\n\nAfter plenty of research and brainstorming, we decided to evolve the existing Simply Accessible brand. Or, rather, salvage what we could. There was no established logo to carry into the new design (it was a stretch to even call it a wordmark), and the Helvetica typography across the site lacked any character. The only recognizable feature left to work with was colour. It was a challenge, for sure: the oranges looked murky and brown, and the blues looked way too corporate for a company like Simply Accessible. We knew we needed to inject a lot of personality.\n\nThe old Simply Accessible website and colour palette.\n\nAfter an audit to round up every colour used throughout the site, we dug in deep and played around with some ideas to bring some new life to this palette. \n\nChoose effective colours\n\nWhether you\u2019re starting from scratch or evolving an existing brand, the first step to having an effective and legible palette begins with your colour choices. While we aren\u2019t going to cover colour message and meaning in this article, it\u2019s important to understand how to choose colours that can be used to create strong contrast\u2014one of the most important ways to create hierarchy, focus, and legibility in your design.\n\nThere are a few methods of creating effective contrast.\n\nLight and dark colours\n\nThe contrast that exists between light and dark colours is the most important attribute when creating effective contrast.\n\nTry not to use colours that have a similar lightness next to each other in a design.\n\n\n\nThe red and green colours on the left share a similar lightness and don\u2019t provide enough contrast on their own without making some adjustments. Removing colour and showing the relationship in greyscale reveals that the version on the right is much more effective. \n\nIt\u2019s important to remember that red and green colour pairs cause difficulty for the majority of colour-blind people, so they should be avoided wherever possible, especially when placed next to each other. \n\nComplementary contrast\n\n\n\nEffective contrast can also be achieved by choosing complementary colours (other than red and green), that are opposite each other on a colour wheel.\n\nThese colour pairs generally work better than choosing adjacent hues on the wheel.\n\nCool and warm contrast\n\nContrast also exists between cool and warm colours on the colour wheel.\n\nImagine a colour wheel divided into cool colours like blues, purples, and greens, and compare them to warm colours like reds, oranges and yellows.\n\n\n\nChoosing a dark shade of a cool colour, paired with a light tint of a warm colour will provide better contrast than two warm colours or two cool colours. \n\nDevelop colour concepts\n\nAfter much experimentation, we settled on a simple, two-colour palette of blue and orange, a cool-warm contrast colour scheme. We added swatches for call-to-action messaging in green, error messaging in red, and body copy and form fields in black and grey. Shades and tints of blue and orange were added to illustrations and other design elements for extra detail and interest.\n\nFirst stab at a new palette.\n\nWe introduced the new palette for the first time on an internal project to test the waters before going full steam ahead with the website. It gave us plenty of time to get a feel for the new design before sharing it with the public.\n\nPutting the test palette into practice with an internal report\n\nIt\u2019s important to be open to changes in your palette as it might need to evolve throughout the design process. Don\u2019t tell your client up front that this palette is set in stone. If you need to tweak the colour of a button later because of legibility issues, the last thing you want is your client pushing back because it\u2019s different from what you promised.\n\nAs it happened, we did tweak the colours after the test run, and we even adjusted the logo\u2014what looked great printed on paper looked a little too light on screens.\n\nConsider how colours might be used\n\nDon\u2019t worry if you haven\u2019t had the opportunity to test your palette in advance. As long as you have some well-considered options, you\u2019ll be ready to think about how the colour might be used on the site or app. \n\nObviously, in such early stages it\u2019s unlikely that you\u2019re going to know every element or feature that will appear on the site at launch time, or even which design elements could be introduced to the site later down the road. There are, of course, plenty of safe places to start.\n\nFor Simply Accessible, I quickly mocked up these examples in Illustrator to get a handle on the elements of a website where contrast and legibility matter the most: text colours and background colours. While it\u2019s less important to consider the contrast of decorative elements that don\u2019t convey essential information, it\u2019s important for a reader to be able to discern elements like button shapes and empty form fields.\n\nA basic list of possible colour combinations that I had in mind for the Simply Accessible website\n\nRun initial tests\n\nOnce these elements were laid out, I manually plugged in the HTML colour code of each foreground colour and background colour on Lea Verou\u2019s Contrast Checker. I added the results from each colour pair test to my document so we could see at a glance which colours needed adjustment or which colours wouldn\u2019t work at all.\n\nNote: Read more about colour accessibility and contrast requirements\n\n\n\n\n\nAs you can see, a few problems were revealed in this test. To meet the minimum AA compliance, we needed to slightly darken the green, blue, and orange background colours for text\u2014an easy fix. A more complicated problem was apparent with the button colours. I had envisioned some buttons appearing over a blue background, but the contrast ratios were well under 3:1. Although there isn\u2019t a guide in WCAG for contrast requirements of two non-text elements, the ISO and ANSI standard for visible contrast is 3:1, which is what we decided to aim for.\n\nWe also checked our colour combinations in Color Oracle, an app that simulates the most extreme forms of colour blindness. It confirmed that coloured buttons over blue backgrounds was simply not going to work. The contrast was much too low, especially for the more common deuteranopia and protanopia-type deficiencies.\n\nHow our proposed colour pairs could look to people with three types of colour blindness\n\nMake adjustments if necessary\n\n\n\nAs a solution, we opted to change all buttons to white when used over dark coloured backgrounds. In addition to increasing contrast, it also gave more consistency to the button design across the site instead of introducing a lot of unnecessary colour variants.\n\nPutting more work into getting compliant contrast ratios at this stage will make the rest of implementation and testing a breeze. When you\u2019ve got those ratios looking good, it\u2019s time to move on to implementation.\n\nImplement colours in style guide and prototype\n\nOnce I was happy with my contrast checks, I created a basic style guide and added all the colour values from my colour exploration files, introduced more tints and shades, and added patterned backgrounds. I created examples of every panel style we were planning to use on the site, with sample text, links, and buttons\u2014all with working hover states. Not only does this make it easier for the developer, it allows you to check in the browser for any further contrast issues.\n\n\n\n\n\nRun a final contrast check\n\nDuring the final stages of testing and before launch, it\u2019s a good idea to do one more check for colour accessibility to ensure nothing\u2019s been lost in translation from design to code. Unless you\u2019ve introduced massive changes to the design in the prototype, it should be fairly easy to fix any issues that arise, particularly if you\u2019ve stayed on top of updating any revisions in the style guide.\n\nOne of the more well-known evaluation tools, WAVE, is web-based and will work in any browser, but I love using Chrome\u2019s Accessibility Tools. Not only are they built right in to the Inspector, but they\u2019ll work if your site is password-protected or private, too.\n\nChrome\u2019s Accessibility Tools audit feature shows that there are no immediate issues with colour contrast in our prototype \n\nThe human touch\n\nFinally, nothing beats a good round of user testing. Even evaluation tools have their flaws. Although they\u2019re great at catching contrast errors for text and backgrounds, they aren\u2019t going to be able to find errors in non-text elements, infographics, or objects placed next to each other where discernible contrast is important. \n\n\n\nOur final palette, compared with our initial ideas, was quite different, but we\u2019re proud to say it\u2019s not just compliant, but shows Simply Accessible\u2019s true personality. Who knows, it may not be final at all\u2014there are so many opportunities down the road to explore and expand it further.\n\n\n\nAccessibility should never be an afterthought in a project. It\u2019s not as simple as adding alt text to images, or running your site through a compliance checker at the last minute and assuming that a pass means everything is okay. Considering how colour will be used during every stage of your project will help avoid massive problems before launch, or worse, launching with serious issues. \n\nIf you find yourself working on a personal project over the Christmas break, try integrating these checks into your workflow and make colour accessibility a part of your New Year\u2019s resolutions.", "year": "2014", "author": "Geri Coady", "author_slug": "gericoady", "published": "2014-12-22T00:00:00+00:00", "url": "https://24ways.org/2014/integrating-contrast-checks-in-your-web-workflow/", "topic": "design"}
{"rowid": 27, "title": "Putting Design on the Map", "contents": "The web can leave us feeling quite detached from the real world. Every site we make is really just a set of abstract concepts manifested as tools for communication and expression. At any minute, websites can disappear, overwritten by a newfangled version or simply gone. I think this is why so many of us have desires to create a product, write a book, or play with the internet of things. We need to keep in touch with the physical world and to prove (if only to ourselves) that we do make real things.\n\nI could go on and on about preserving the web, the challenges of writing a book, or thoughts about how we can deal with the need to make real things. Instead, I\u2019m going to explore something that gives us a direct relationship between a website and the physical world \u2013 maps.\n\n\n\tA map does not just chart, it unlocks and formulates meaning; it forms bridges between here and there, between disparate ideas that we did not know were previously connected.\nReif Larsen, The Selected Works of T.S. Spivet\n\n\nThe simplest form of map on a website tends to be used for showing where a place is and often directions on how to get to it. That\u2019s an incredibly powerful tool. So why is it, then, that so many sites just plonk in a default Google Map and leave it as that? You wouldn\u2019t just use dark grey Helvetica on every site, would you? Where\u2019s the personality? Where\u2019s the tailored experience? Where is the design?\n\nJumping into design\n\nLet\u2019s keep this simple \u2013 we all want to be better web folk, not cartographers. We don\u2019t need to go into the history, mathematics or technology of map making (although all of those areas are really interesting to research). For the sake of our sanity, I\u2019m going to gloss over some of the technical areas and focus on the practical concepts.\n\nTiles\n\nIf you\u2019ve ever noticed a map loading in sections, it\u2019s because it uses tiles that are downloaded individually instead of requiring the user to download everything that they might need. These tiles come in many styles and can be used for anything that covers large areas, such as base maps and data. You\u2019ve seen examples of alternative base maps when you use Google Maps as Google provides both satellite imagery and road maps, both of which are forms of base maps. They are used to provide context for the real world, or any other world for that matter. A marker on a blank page is useless.\n\nThe tiles are representations of the physical; they do not have to be photographic imagery to provide context. This means you can design the map itself. The easiest way to conceive this is by comparing Google\u2019s road maps with Ordnance Survey road maps. Everything about the two maps is different: the colours, the label fonts and the symbols used. Yet they still provide the exact same context (other maps may provide different context such as terrain contours).\n\n Comparison of Google Maps (top) and the Ordnance Survey (bottom).\n\nCarefully designing the base map tiles is as important as any other part of the website. The most obvious, yet often overlooked, aspect are aesthetics and branding. Maps could fit in with the rest of the site; for example, by matching the colours and line weights, they can enhance the full design rather than inhibiting it. You\u2019re also able to define the exact purpose of the map, so instead of showing everything you could specify which symbols or labels to show and hide.\n\nI\u2019ve not done any real research on the accessibility of base maps but, having looked at some of the available options, I think a focus on the typography of labels and the colour of the various elements is crucial. While you can choose to hide labels, quite often they provide the data required to make sense of the map. Therefore, make sure each zoom level is not too cluttered and shows enough to give context. Also be as careful when choosing the typeface as you are in any other design work. As for colour, you need to pay closer attention to issues like colour-blindness when using colour to convey information. Quite often a spectrum of colour will be used to show data, or to show the topography, so you need to be aware that some people struggle to see colour differences within a spectrum.\n\nA nice example of a customised base map can be found on Michael K Owens\u2019 check-in pages:\n\n One of Michael K Owens\u2019 check-in pages.\n\nAs I\u2019ve already mentioned, tiles are not just for base maps: they are also for data. In the screenshot below you can see how Plymouth Marine Laboratory uses tiles to show data with a spectrum of colour.\n\n A map from the Marine Operational Ecology data portal, showing data of adult cod in the North Sea.\n\nTechnical\n\nYou\u2019re probably wondering how to design the base layers. I will briefly explain the concepts here and give you tools to use at the end of the article. If you\u2019re worried about the time it takes to design the maps, don\u2019t be \u2013 you can automate most of it. You don\u2019t need to manually draw each tile for the entire world!\n\nWe\u2019ve learned the importance of web standards the hard way, so you\u2019ll be glad (and I won\u2019t have to explain the advantages) of the standard for web mapping from the Open Geospatial Consortium (OGC) called the Web Map Service (WMS). You can use conventional file formats for the imagery but you need a way to query for the particular tiles to show for the area and zoom level, that is what WMS does.\n\nFeatures\n\nTiles are great for covering large areas but sometimes you need specific smaller areas. We call these features and they usually consist of polygons, lines or points. Examples include postcode boundaries and routes between places, or even something more dynamic such as borders of nations changing over time.\n\nShowing features on a map presents interesting design challenges. If the colour or shape conveys some kind of data beyond geographical boundaries then it needs to be made obvious. This is actually really hard, without building complicated user interfaces. For example, in the image below, is it obvious that there is a relationship between the colours? Does it need a way of showing what the colours represent?\n\n Choropleth map showing ranked postcode areas, using ViziCities.\n\n\n\tFeatures are represented by means of lines or colors; and the effective use of lines or colors requires more than knowledge of the subject \u2013 it requires artistic judgement.\nErwin Josephus Raisz, cartographer (1893\u20131968)\n\n\nWhere lots of boundaries are small and close together (such as a high street or shopping centre) will it be obvious where the boundaries are and what they represent? When designing maps, the hardest challenge is dealing with how the data is represented and how it is understood by the user.\n\nTechnical\n\nAs you probably gathered, we use WMS for tiles and another standard called the web feature service (WFS) for specific features. I need to stress that the difference between the two is that WMS is for tiling, whereas WFS is for specific features. Both can use similar file formats but should be used for their particular use cases. You may be wondering why you can\u2019t just use a vector format such as KML, GeoJSON (or even SVG) \u2013 and you can \u2013 but the issue is the same as for WMS: you need a way to query the data to get the correct area and zoom level.\n\nUser interface\n\nThere is of course never a correct way to design an interface as there are so many different factors to take into consideration for each individual project. Maps can be used in a variety of ways, to provide simple information about directions or for complex visualisations to explain large amounts of data. I would like to just touch on matters that need to be taken into account when working with maps.\n\nAs I mentioned at the beginning, there are so many Google Maps on the web that people seem to think that its UI is the only way you can use a map. To some degree we don\u2019t want to change that, as people know how to use them; but does every map require a zoom slider or base map toggle? In fact, does the user need to zoom at all? The answer to that one is generally yes, zooming does provide more context to where the map is zoomed in on.\n\nIn some cases you will need to let users choose what goes on the map (such as data layers or directions), so how do they show and hide the data? Does a simple drop-down box work, or do you need search? Google\u2019s base map toggle is quite nice since it doesn\u2019t offer many options yet provides very different contexts and styling.\n\nIt isn\u2019t until we get to this point that we realise just plonking a quick Google map is really quite ridiculous, especially when compared to the amount of effort we make in other areas such as colour, typography or how the CSS is written. Each of these is important but we need to make sure the whole site is designed, and that includes the maps as much as any other content.\n\nPutting it into practice\n\nI could ramble on for ages about what we can do to customise maps to fit a site\u2019s personality and correctly represent the data. I wanted to focus on concepts and standards because tools constantly change and it is never good to just rely on a tool to do the work. That said, there are a large variety of tools that will help you turn these concepts into reality. This is not a comparison; I just want to show you a few of the many options you have for maps on the web.\n\nGoogle\n\nOK, I\u2019ve been quite critical so far about Google Maps but that is only because there is such a large amount of the default maps across the web. You can style them almost as much as anything else. They may not allow you to use custom WMS layers but Google Maps does have its own version, called styled maps. Using an array of map features (in the sense of roads and lakes and landmarks rather than the kind WFS is used for), you can style the base map with JavaScript. It even lets you toggle visibility, which helps to avoid the issue of too much clutter on the map. As well as lacking WMS, it doesn\u2019t support WFS, but it does support GeoJSON and KML so you can still show the features on the map. You should also check out Google Maps Engine (the new version of My Maps), which provides an interface for creating more advanced maps with a selection of different base maps. A premium version is available, essentially for creating map-based visualisations, and it provides a step up from the main Google Maps offering. A useful feature in some cases is that it gives you access to many datasets.\n\nLeaflet\n\nYou have probably seen Leaflet before. It isn\u2019t quite as popular as Google Maps but it is definitely used often and for good reason. Leaflet is a lightweight open source JavaScript library. It is not a service so you don\u2019t have to worry about API throttling and longevity. It gives you two options for tiling, the ability to use WMS, or to directly get the file using variables in the filename such as /{z}/{x}/{y}.png. I would recommend using WMS over dynamic file names because it is a standard, but the ability to use variables in a file name could be useful in some situations. Leaflet has a strong community and a well-documented API.\n\nMapbox\n\nAs a freemium service, Mapbox may not be perfect for every use case but it\u2019s definitely worth looking into. The service offers incredible customisation tools as well as lots of data sources and hosting for the maps. It also provides plenty of libraries for the various platforms, so you don\u2019t have to only use the maps on the web.\n\nMapbox is a service, though its map design tool is open source. Mapbox Studio is a vector-only version of their previous tool called Tilemill. Earlier I wrote about how typography and colour are as important to maps as they are to the rest of a website; if you thought, \u201cYes, but how on earth can I design those parts of a map?\u201d then this is the tool for you. It is incredibly easy to use. Essentially each map has a stylesheet.\n\nIf you do not want to open a paid-for Mapbox account, then you can export the tiles (as PNG, SVG etc.) to use with other map tools.\n\nOpenLayers\n\nAfter a long wait, OpenLayers 3 has been released. It is similar to Leaflet in that it is a library not a service, but it has a much broader scope. During the last year I worked on the GIS portal at Plymouth Marine Laboratory (which I used to show the data tiles earlier), it essentially used OpenLayers 2 to create a web-based geographic information system, taking a large amount of data and permitting analysis (such as graphs) without downloading entire datasets and complicated software. OpenLayers 3 has improved greatly on the previous version in both performance and accessibility. It is the ideal tool for complex map-based web apps, though it can be used for the simple use cases too.\n\nOpenStreetMap\n\nI couldn\u2019t write an article about maps on the web without at least mentioning OpenStreetMap. It is the place to go for crowd-sourced data about any location, with complete road maps and a strong API.\n\nViziCities\n\nThe newest project on this list is ViziCities by Robin Hawkes and Peter Smart. It is a open source 3-D visualisation tool, currently in the very early stages of development. The basic example shows 3-D buildings around the world using OpenStreetMap data. Robin has used it to create some incredible demos such as real-time London underground trains, and planes landing at an airport. Edward Greer and I are currently working on using ViziCities to show ideal housing areas based on particular personas. We chose it because the 3-D aspect gives us interesting possibilities for the data we are able to visualise (such as bar charts on the actual map instead of in the UI). Despite not being a completely stable, fully featured system, ViziCities is worth taking a look at for some use cases and is definitely going to go from strength to strength.\n\n\n\nSo there you have it \u2013 a whistle-stop tour of how maps can be customised. Now please stop plonking in maps without thinking about it and design them as you design the rest of your content.", "year": "2014", "author": "Shane Hudson", "author_slug": "shanehudson", "published": "2014-12-11T00:00:00+00:00", "url": "https://24ways.org/2014/putting-design-on-the-map/", "topic": "design"}
{"rowid": 28, "title": "Why You Should Design for Open Source", "contents": "Let\u2019s be honest. Most designers don\u2019t like working for nothing. We rally against spec work and make a stand for contracts and getting paid. That\u2019s totally what you should do as a professional designer in the industry. It\u2019s your job. It\u2019s your hard-working skill. It\u2019s your bread and butter. Get paid.\n\nHowever, I\u2019m going to make a case for why you could also consider designing for open source. First, I should mention that not all open source work is free work. Some companies hire open source contributors to work on their projects full-time, usually because that project is used by said company. There are other companies that encourage open source contribution and even offer 20%-time for these projects (where you can spend one day a week contributing to open source). These are super rad situations to be in. However, whether you\u2019re able to land a gig doing this type of work, or you\u2019ve decided to volunteer your time and energy, designing for open source can be rewarding in many other ways.\n\nPortfolio building\n\nNew designers often find themselves in a catch-22 situation: they don\u2019t have enough work experience showcased in their portfolio, which leads to them not getting much work because their portfolio is bare. These new designers often turn to unsolicited redesigns to fill their portfolio. An unsolicited redesign is a proof of concept in which a designer attempts to redesign a popular website. You can see many of these concepts on sites like Dribbble and Behance and there are even websites dedicated to showcasing these designs, such as Uninvited Designs. There\u2019s even a subreddit for them.\n\nThere are quite a few negative opinions on unsolicited redesigns, though some people see things from both sides. If you feel like doing one or two of these to fill your portfolio, that\u2019s of course up to you. But here\u2019s a better suggestion. Why not contribute design for an open source project instead?\n\nYou can easily find many projects in great need of design work, from branding to information design, documentation, and website or application design. The benefits to doing this are far better than an unsolicited redesign. You get a great portfolio piece that actually has greater potential to get used (especially if the core team is on board with it). It\u2019s a win-win situation.\n\nNot all designers are in need of portfolio filler, but there are other benefits to contributing design.\n\nGiving back to the community\n\nMy first experience with voluntary work was when I collaborated with my friend, Vineet Thapar, on a pro bono project for the W3C\u2019s Web Accessibility Initiative redesign project back in 2004. I was very excited to contribute CSS to a website that would get used by the W3C! Unfortunately, it decided to go a different direction and my work did not get used. However, it was still pretty exciting to have the opportunity, and I don\u2019t regret a moment of that work. I learned a lot about accessibility from this experience and it helped me land some of the jobs I\u2019ve had since.\n\nAlmost a decade later, I got super into Sass. One of the core maintainers, Chris Eppstein, lamented on Twitter one day that the Sass website and brand was in dire need of design help. That led to the creation of an open source task force, Team Sass Design, and we revived the brand and the website, which launched at SassConf in 2013.\n\nIt helped me in my current job. I showed it during my portfolio review when I interviewed for the role. Then I was able to use inspiration from a technique I\u2019d tried on the Sass website to help create the more feature-rich design system that my team at work is building. But most importantly, I soon learned that it is exhilarating to be a part of the Sass community. This is the biggest benefit of all. It feels really good to give back to the technology I love and use for getting my work done.\n\nBen Werdmuller writes about the need for design in open source. It\u2019s great to see designers contributing to open source in awesome ways. When A List Apart\u2019s website went open source, Anna Debenham contributed by helping build its pattern library. Bevan Stephens worked with FontForge on the design of its website. There are also designers who have created their own open source projects. There\u2019s Dan Cederholm\u2019s Pears, which shares common patterns in markup and style. There\u2019s also Brad Frost\u2019s Pattern Lab, which shares his famous method of atomic design and applies it to a design system. These systems and patterns have been used in real-world projects, such as RetailMeNot, so designers have contributed to the web in an even larger way simply by putting their work out there for others to use. That\u2019s kind of fun to think about.\n\nHow to get started\n\nSo are you stoked about getting into the open source community? That\u2019s great!\n\nInitially, you might get worried or uncomfortable in getting involved. That\u2019s okay. But first consider that the project is open source for a reason. Your contribution (no matter how large or small) can help in a big way.\n\nIf you find a project you\u2019re interested in helping, make sure you do your research. Sometimes project team members will be attached to their current design. Is there already a designer on the core team? Reach out to that designer first. Don\u2019t be too aggressive with why you think your design is better than theirs. Rather, offer some constructive feedback and a proposal of what would make the design better. Chances are, if the designer cares about the project, and you make a strong case, they\u2019ll be up for it.\n\nAre there contribution guidelines? It\u2019s proper etiquette to read these and follow the community\u2019s rules. You\u2019ll have a better chance of getting your work accepted, and it shows that you take the time to care and add to the overall quality of the project. Does the project lack guidelines? Consider starting a draft for that before getting started in the design.\n\nWhen contributing to open source, use your initiative to solve problems in a manageable way. Huge pull requests are hard to review and will often either get neglected or rejected. Work in small, modular, and iterative contributions.\n\nSo this is my personal take on what I\u2019ve learned from my experience and why I love open source. I\u2019d love to hear from you if you have your own experience in doing this and what you\u2019ve learned along the way as well. Please share in the comments!\n\nThanks Drew McLellan, Eric Suzanne, Kyle Neath for sharing their thoughts with me on this!", "year": "2014", "author": "Jina Anne", "author_slug": "jina", "published": "2014-12-19T00:00:00+00:00", "url": "https://24ways.org/2014/why-you-should-design-for-open-source/", "topic": "design"}