Johan Ronsse
  • Home
  • Projects
  • Blog

  • Join the Doccle design team as a UI/UX designer

    May 4, 2024 - Posted in doccle hiring jobs

    At Doccle, we are seeking a talented UI/UX designer with a passion for creating intuitive and engaging user interfaces.

    Who we are looking for exactly is listed on this job listing. In short, we are looking for a candidate with 2-5 years of experience, that is ready to join a product team focussed on quality.

    I want to give a bit of backstory for those considering applying.

    At Doccle, I’ve been building up the design team to improve the product. After 2,5 years of work we now have two great design systems in place for both our web and mobile apps. The Doccle team grew from approximately 20 people when I joined to 50 people.

    We have great workflows for making sure that the design work is correctly tied to the software roadmap and any ticketing.

    Lately there is a big emphasis on user research and validating the proposed solutions with a real user base. Both qualitative and quantitative research contribute to studying subject matter before starting to develop it. We have over 3 million users. There is a wealth of information to draw from.

    Sometimes it’s hard to “UX research” the thing before it gets developed (you know: the old “if I asked people what they wanted…”) – for this we have data-based experiments, complete with analytics tracking, across all touchpoints. All of the above informs our software development roadmap.

    The design team works mostly on the product side, where you will work together with analysts and product managers to get to a great end result. Examples of work include payment flows, document management flows and exploring exciting new features such as data sharing.

    I don’t know about you but I have this special obsession for great administrative workflows, and it’s quite fun to work on optimizing the way a small independent would do their quarterly return in Doccle.

    When I was working on Mono we had a big emphasis on how, when a designer joined the team, we would let them grow in their careers. We would help them with missing gaps in their skillset and finding the golden combination between what the company needed, what the person wanted to grow in, and what they were already good at. I want to apply the management techniques I learned at Mono in the Doccle context. What this means for you, as a candidate, is that I will take special care in mentoring you as a designer.

    The team also has a great link with the marketing and front-end dev teams. There is a website that documents the brand, and the overall assets used have a cross-over between design and marketing. With the web front-end devs we discuss new design components and how they relate to the overall front-end pattern library. With the native mobile devs, we discuss the correct usage of iOS/Android patterns as we translate features to be available on every platform with respect for the design language of each platform.

    I truly believe this is a great and unique position, and there are few product positions like this in Belgium. You would have to look abroad to find the kinds of companies with so many users, where the actual digital product is the primary focal point.

    Next to a full-time designer, we are also looking into an internship/apprenticeship in school year 2024-2025. We are mostly looking at people who are studying Digital Experience Design at IMD or Devine.

    If you are interested, we would love you to to apply using the instructions in the post.

    I will be in Belgium the next few weeks, just phone me during office hours: +32 479 29 86 81 or e-mail my Doccle mail: johan.ronsse@doccle.be.

  • How to build zero to one inside a company

    April 27, 2024 - Posted in figma product

    This video really spoke to me. Mihika’s product management style reminds me of how I work, a lot! I was nodding in agreement all the way. Must-watch if you are involved in product decisions in any way.

  • Feedback 🤝 Feedback

    April 23, 2024 - Posted in development figma figma-plugins screenshot-to-layout

    I am looking for people who want to test drive the new Screenshot to Layout plugin for Figma.

    I am specifically looking for people who want to jump on a short call, share their screen and share their experience. It would be awesome to do some usability testing after all these months of work.

    If you are more of a no-meeting person, but still want to give feedback, feel free to check out the new version here. I won’t say too much so you can figure it out. Feel free to send me the feedback.

    Interested? Get in touch: e-mail me at stl@johanronsse.be . If you want, I can do a test drive of your product or give a quick design crit. Feedback for feedback, as it were!

  • Type variables in Figma – variable font workaround

    April 20, 2024 - Posted in figma typography

    Having been released this week, type variables are the new hotness in Figma. If you want to know the details I recommend this excellent post by Joey Banks.

    While his post is a general overview, this blog post is more about solving a specific niche issue: the design system I work on uses variable fonts, which are not supported yet in Figma’s variable logic.

    Variable fonts have the concept of axises, for example width, grad, slant etc.; you can customize the variable font along an axis. For example you can set the value of “width” to be a value between 25 and 151 in Roboto Flex. You can this for yourself online here.

    Now, Figma allows you to target the font family using string variables, letter spacing using number variables, font size using numbers variables… but not the specific axises for variable fonts. It’s unfortunate this did not make the release but to be fair, this is also extremely difficult to implement, since there are an infinite number of axises possible and there is no standardization across fonts.

    But, since you name target a font family by name, and there is a likelihood that you only need a very specific “setting” of a variable font, a temporary workaround that might help you is to “slice” a variable font so it essentially only contains only the axis settings you will use.

    Using the amazing Slice tool you can export a version of a font with the specific settings you choose “baked in”. What I did for my own needs was to export 3 variations of Roboto Flex with the axis of width set to 110, 115 and 120. I needed this to simulate the look of Proxima Nova on Android, while still retaining that Android feel.

    And lo and behold, it worked.

    Notice the “Roboto Flex Custom 120” style for Android.

    Make sure to give it a unique name (postscript and others) so when you import it in your system fonts, it doesn’t conflict with the existing font.

    Now all that is left for you is to distribute the font files with your colleagues, make sure you are OK when it comes to licensing, and enjoy your new variable type system.

    I really hope this tip helps someone move their design system along using this awesome new Figma feature.

  • Overindexing on the system

    March 26, 2024 - Posted in product - 1 comment

    Have you ever seen the LEGO documentary on Disney+? It talks about the history of LEGO and if you’ve seen it, you might be familiar with a phrase that’s said many times in this documentary: new Lego products should be part of the system.

    The original LEGO designers envisioned a system, mostly based around the grid pattern and being able to snap pieces into each other. Bricks that follow this system are the classic 2×4 Lego brick, a 2×2 brick and others (like half height bricks). They envisioned that with this system, you could basically create anything you wanted.

    However, as the documentary progresses, it talks about how new people came in with new ideas, and these new ideas were not necessarily part of the system. The new pieces did not fit the original system, used another system altogether or were difficult to mass-produce. They were very set-specific and didn’t play well with other sets. Consequently, they did not fit the system.

    Naturally, this caused a lot of discussions within LEGO.

    As a designer that is both responsible for envisioning designs that work across hundreds of screens and with a fair bit of experience in design systems, I find myself on the side of the discussion of the original LEGO designers sometimes: the new component/icon/code etc. has to fit the system.

    But then, sometimes I am envisioning something entirely new; and at this point, in an early design stage, it’s not very helpful – not even to me – to see how it would fit the system. However, as you get closer to the implementation reality (also see: the three types of product designs); you inevitably have to check how whatever you are designing fits the system.

    Another case could be that the implementation is not a real implementation but demoware, in which case, you might have to deal with the fact that you are implementing something in the system, which is not actually part of the system, but it might be after it’s validated. Or you might have to deal with people who now think it’s part of the system, when to you, it’s not.

    As a product designer you are expected to be able navigate around all these realities, depending on which conversation you are having. This can lead to very schizophrenic conversations where on one hand, something exists in a given system (e.g. design library), yet it is not implemented in another system (e.g. front-end library) yet an expectation exists from stakeholders that it’s there. The work to bring the system together is typically undervalued by stakeholders since it’s not considered “real work” (which seems really weird to me); but if you skip that kind of work, my experience is that the end result suffers tremendously.

    A weird thing that happened the past years is that, because design systems demanded so much attention, and front-end developers screamed a bit much to put attention towards these systems – something making the system the actual work, instead of the end result – design systems kind of got a bad rap by managers. I believe some people burned design systems by forgetting the reason behind them – implementing actual user and business value.

    I am the first to say there is too much design systems & component talk in general, and people should focus on results, but I seem to have internalized the design system approach enough in a way that it’s obvious to me how to move things across from Figma to a front-end library.

    Depending on who you are talking to it is not that obvious and it’s up to you as the designer to find a way to make the actual very explicit (in order to do A, we need B, C and D).

    Then from another standpoint, as a product stakeholder, it might be worthwhile to think ahead, that if you want your idea to make it into reality, maybe it’s better if it… fits the system? But here I diverge, and I am not really talking about front-end components here, but about fitting into the universal vision of the product. But that’s maybe a topic to revisit later.

    If you enjoy these product posts or something stood out to you, let me know, because I am not sure if I am rambling or making sense. In any case I enjoyed the writing of these myself.

  • Three types of product designs

    March 25, 2024 - Posted in design product

    In the previous post, I wrote:

    Designing gives you the chance to evaluate solutions before they have to be implemented. You diverge to converge. There is still a possibility space, but once you are in the implementation zone, that space changes to more of an impossibility space. Scope gets locked down and in order to achieve a timing, you can not add more ideas to the table.

    If you are in a semi-waterfall logic, the quality of your initial ideas becomes more important. And let’s be honest, when you’re designing software, most of us are in a waterfall process at some level.

    Surely there is some leeway in influencing the idea while it’s in development, but the space you move in severely limited by whatever analysis and design work was done before you, typically already limiting the possibility space. And it’s not just limited by your design; the limit might also come from an analysis, prior design, or legacy part of your software.

    Not every type of design work follows the above order of going from idea to implementation. Some designs stay in the possibility space, and are specifically meant to be an output to help further business discussions; or are meant to gauge product/market fit.

    I’ve had to learn to navigate the space of having hundreds of active designs, where some of them are closer to an implementation and some are merely an idea.

    I’ve identified three types of designs in product and categorize them as A, B and C designs:

    • A-type designs: The scope is more or less defined, there is an analysis, this design is going to development soon. Detailed questions about edge cases should have answers, and the design better be in a ready-to-implement state.
    • B-type designs: The scope is probably to be developed in 4-8 months but might also be cut. You are exploring solutions with much more possibility for divergence than in A-type designs. You are working towards a solution, but it’s OK if not everything has been thought through.
    • C-type designs: this design is not meant to be implemented at all, and does not have to take into account the reality of development. This design is meant to evolve a stakeholder discussion, to drive a client conversation, to simply document an idea, or to provide a vision and blueprint for the future that can inform B-type designs.

    So, that’s it for today. My next post I would like to focus on some oddities that are going on in product regarding design systems.

    If you like my writing about product, let me know, because I don’t know if these ramblings resonate with other designers/devs/product people!

  • 2 years of in-house product design

    March 20, 2024 - Posted in blijvend-leren career design

    A few days ago marked the day I’ve been working in-house for 2 years. I think overall I am very happy with my decision to go in-house as a product designer. I gained a new perspective by working on a product full-time for a longer time. The depth in which you can go as an in-house designer when compared to agency work is incredible.

    The other day I was investigating the voiceover implementation in our native iOS and Android apps.

    Sometimes there is work that forms itself over many months. For example over the past two years I’ve tried to hold a tight guard on improved branding of Doccle overall, with some successes and some ways to go. Another ongoing project is moving Doccle to be a primary example of a great native-looking iOS and Android app, that embraces Apple and Google’s respective design languages. I’m happy with the steps that have been taken and that we are taking.

    Now, it’s only logical that your work goes deeper because you have many months to work on similar problems. I keep remembering is this tweet by someone from Github that you better document your work in product, because it’s going to come back anyway. My CEO tells me he sometimes feels like the living memory of Doccle.

    Some activities of the past two years included working on user interface designs, doing user research, tackling brand and visual design, writing front-end code, work on product strategy, improve and write new copy (in 4 languages), … and so much more.

    As a designer, I am and always looking for opportunities to improve what we have.

    Sometimes this is perceived as a kind of permanent unhappiness, and it can really get on the nerves of colleagues. Navigating stakeholders and decisions when you are sometimes basically stepping on someone’s work is its own challenge. I’ve learned to be more polite and more considerate of past work.

    I’ve also learned that you can’t simply change something because you want to change it. The change has to be an improvement. Moreso, the change needs to have all blocking questions answered and depending on what it is, need to be thought through end-to-end. This is not always the case, but for things shipping to millions of users, it is.

    The desire for change causes issues for others in the company. Change can mean disruption.

    Arriving with my agency perspective I quickly started work on improved designs, only to find out that the company didn’t move as fast as my designs did. I made designs that I knew best – category interactions – filterable datagrids. Tidied up design systems. Then, it took a while to get implemented.

    At first I attributed it to the company, but I believe it’s a reality of product. I came in with the naive expectation that if I would design it, it would get implemented. Boy, was I wrong.

    When I was designing in an agency context, I rarely saw the actual implementation side; we consulted and came up with designs, but we often didn’t see how long it would take to get to an implementation. Or, we would specifically be hired for a redesign track, so the redesign was already decided within the company we were working for.

    At Mono, we knew in the back of our heads that we finished up a project 6 or 12 months ago. Sometimes we got updates, but sometimes we didn’t hear about it anymore. Then, two years after a design we’d suddenly see a public implementation of our work pop up. Not every project would follow this pattern but it happened more than I liked.

    I’ve now internalized the reality of a product moving much slower than the designs. Basically you are there during the whole timeframe of the implementation. But the detail you go into is so much deeper. From lokalisation in four languages, to designing the same feature across three platforms with multiple form factors, to overseeing the final implementation details.

    I learned that as a product designer, you are moving across different types of design. This was not as apparent in agency work. I feel like we often got hired for execution, and not for research or problem definition. When we got hired, we already knew what the problem was. This is not always the case now, and thus I’ve been improving my research skills.

    Designing gives you the chance to evaluate solutions before they have to be implemented. You diverge to converge. There is still a possibility space, where once you are in the implementation zone, that space changes more to an impossibility space. Scope gets locked down and in order to achieve a timing, you can not add more ideas to the table. In a next post I want to elaborate more on the three types of product designs I’ve identified.

  • The case for design engineers

    February 13, 2024 - Posted in design development product

    Good post from Jim Nielsen about the case for design engineers. He gives a good example of the kind of implementation detail where you might need insight from both the design and dev perspective. I find that some of my best work came from where code intersected with design.

    Lately I am on a path involving a lot of pixel perfect design with a semi-traditional handoff, combined with research.

    Sometimes I yearn for the days of yore where I did not have to direct details from a distance, only hoping that the implementation matches my dreams. Moreover, the whole problem with trying to describe something is that your description will just be incomplete; you have to feel the implementation, you have to be actually use it.

    One problem I have is the multi-platform-ness of our implementation (iOS/iPadOS/Android/Web), combined with the actual design problems and research; which does not leave me with time to also concern myself about code.

    But when I do, I get a lot of pushback when I push for prototypes, with the arguments that it’s going to lead to throwaway code; will not fit in the system; or I just seem to leave the other side of the table puzzled with what I am talking about.

    The point that my respondents in my opinion do not get, is that the point of a prototype is to get to a conclusion, to learn something. You can then go ahead and implement the actual thing in production ready code. A prototype can be throwaway code, specifically because it helps you on your path to learning where you need to be in the end. The deliverable is testable and something to iterate further on.

    In my experience, when talking about a semi-complex UI, iterating on something once is just simply not enough. I find that in practice that it happens all the time that a design goes straight to implementation.

  • Mexico (3)

    February 1, 2024 - Posted in lifelog mexico persoonlijk reflectie road-biking

    Ik las net mijn vorige posts over Mexico, die ik schreef op het moment dat ik hier 1,5 maand en 2,5 maand was. Nu ben ik hier één jaar en ongeveer twee maanden. En het ziet ernaar uit dat ik hier nog een hele tijd ga zijn.

    Werk

    Qua werk sta ik nog altijd rond 5u-6u op om de Europese middag mee te pakken. Ik werk bijna uitsluitend voor één grote Belgische/Nederlandse klant. Daarnaast werk ik aan een aantal zijprojecten en uitzonderlijk doe ik iets kleins voor een andere klant.

    De zijprojecten gaan goed, zeker Screenshot to Layout dat telkens meer gebruikers heeft. Dat zijproject ben ik volop verder aan het ontwikkelen met een klein team. Ik kan er momenteel zelf spijtig genoeg weinig tijd voor maken. Hopelijk kan ik het binnenkort een nieuwe schwung geven.

    Ik blijf het voordeel hebben dat ik in de namiddag nooit meetings heb, en dus lekker geconcentreerd kan doorwerken. Ik zie andere designers/developers online vaak klagen over een gebrek aan focustijd en te veel meetings. Dat probleem heb ik zelden.

    Fietsen

    Ik ben in mijn vrije tijd veel bezig met fietsen. Ik had eerst een stadsfiets gekocht, en heb nu ook een koersfiets. Deze week heb ik mijn eerste groepsrit gemaakt en het was heel leuk. Ik wilde eigenlijk een gravelbike kopen (oh de hype), maar ben toch voor de koersfiets gegaan, met het idee dat het wellicht makkelijker zou zijn om groepsritten te vinden voor dat soort fiets. En dat klopt wel, denk ik.

    Het is ook een fietsje dat je technisch naar een semi-gravel bike kan omtoveren, dus als ik ooit eens dat pad op wil dan kan het. Er zijn wel gravel events, maar niet zo veel en je moet om tot in de natuur te geraken je fiets op ‘n auto monteren (of in de koffer gooien), en daar ben ik nog niet. Leuk weetje: één van de bekendere gravel events heet de Belgian Waffle Ride.

    Fietsen in de stad is wel een uitdaging, waar je een beetje moet ontdekken waar je best rijdt en hoe. Ik ben een Whatsapp-groep begonnen voor andere fietsers en heb met een aantal mensen uit de groep afgesproken voor ritjes.

    Elke zondag is er een “ciclothon”. De straten van Mexico stad worden over een lengte van 40-60 km vrijgemaakt en fietsers, skaters en lopers allerhande kunnen zich van 8 tot 14u uitleven op een afgesloten weg.

    Je kunt ook gaan fietsen op het F1-circuit van Mexico-stad. Dat ben ik een jaar geleden ongeveer een keer gaan doen, met toen een geleende fiets, en wil ik binnenkort nog eens proberen – maar nu met de snellere fiets.

    Sim racing & gaming

    Ik mis mijn sim racing opstelling wel. Ik denk regelmatig aan nog eens een investering te doen in een wiel + playseat, maar (1) hoe duur zijn die setups niet geworden? en (2) mijn appartement is toch iets te klein voor een dedicated setup.

    Ondertussen speel ik wat indie games op de Switch of probeer soms een nieuw spel op de gaming PC die ik kocht via Game Pass. De PS4 is hier al even stof aan het vangen. Ik denk soms aan een PS5 maar er zijn niet genoeg goede games. Ik heb ook niet zoveel tijd om te gamen. De nieuwe fietshobby neemt nu mijn aandacht in.

    Eten en drinken

    De restaurants en koffiebars in mijn buurt zijn geweldig. Ik ga regelmatig een koffie halen in mijn vaste stekje. Er is ook een leuke bakkerij in de buurt (en zelfs een frituur!). Er is altijd wel iets nieuws te ontdekken qua eten. Ik kom net van een leuk ramen restaurant; zag weer een nieuwe koffiebar verschijnen; en we gaan regelmatig taco’s eten. De kwaliteit van de keuken hier blijft verbazen.

    De supermarkten hier vind ik nog altijd maar niks en recent vind ik niet echt mijn draai qua ingrediënten en zelf koken. Soms geraak ik wel in een goeie kooklogica met een meal plan in combinatie met iets nieuws proberen, maar we eten toch vaak exact hetzelfde.

    Er zijn hier ook de versmarkten. In het begin denk je dat je op de markten vanalles kan vinden maar het is uiteindelijk toch veel van hetzelfde, met wisselende kwaliteit van de producten. Sommigen zijn toch ook een beetje dodgy.

    Daarnaast ben ik misschien gewoon een beetje lui geworden in de keuken. Het is veel werk om tot de juiste ingredienten te komen om telkens goed te koken. Je hebt ook maar zoveel uren in een dag.

    Cultuur

    Binnenkort is het weer CDMX Art Week, dat is ook iets leuks. Dan zijn er veel feestjes, kunsttentoonstellingen en meer. Ik weet nog niet in hoeverre we iets gaan meepikken, maar zulke dingen doen de stad leven.

    Onlangs gingen we met de familie naar een expo over brutalistische architectuur. Er zijn enorm veel musea en er staat nog wel wat op de te-bezoeken lijst.

    De stadsontwikkeling is ook interessant om te volgen. De stad leeft en evolueert, en er wordt overal bijgebouwd en gewijzigd. Ik sta telkens te kijken van nieuwe gebouwen en hoe de stad blijft veranderen. Met 22,5 miljoen mensen is hier heel wat beweging.

    De taal

    Mijn Spaans wordt steeds beter. Onlangs op een lang weekend heb ik een boek in het Spaans gelezen en denk ik het meeste ervan begrepen. Ik zou wel beter terug echte lessen volgen, maar ik kan een klein gesprek voeren, vlot eten bestellen en ik voel me niet meer verloren.

    Wederom voel ik ietwat tijdsgebrek om echt een structurele taalles te volgen. Ik zou het beter doen, maar de incentive ontbreekt.

    Het weer

    Het weer is geweldig, het hele jaar door 16-28 graden buiten. Een toertje doen in de buurt is heel aangenaam. Wel één minpuntje: het is altijd vroeg donker (18u-20u), dus die lange Belgische zomeravonden heb je niet.

    Andere

    Gentrification is real en ik ben waarschijnlijk een deel van het probleem. Ik heb me ook wel gevestigd in de hippe buurt die er voor bekend staat.

    Moest ik mezelf daarin willen verdedigen kan ik stellen dat ik hier zeker niet ben omdat het hier goedkoper leven is voor een hogere levenskwaliteit. Unlike de vele Amerikanen en Canadezen hier. Ik hoor ook om de haverklap Hollands als ik door de straten loop. Grappig.

    Dat goedkoper leven hier is ook nog wel relatief. Samen betalen we hier veel meer huur dan in België voor een minder kwalitatieve woning en minder vierkante meters. Sommige dingen (zoals GSMs en fietsen) zijn duurder. Andere dingen zijn dan weer veel goedkoper (zoals elektriciteit). Ik heb niet de indruk dat ik hier enorm veel geld bespaar.

    Mexicaanse families zijn erg warm (in ieder geval de mijne). Dat heb ik al een paar keer mogen ervaren, en dat is fijn zo. Wat ook leuk is is dat sommige nieuwe neven & nichten ongeveer dezelfde leeftijd en gelijkaardige interesses hebben. Om een idee te geven: ik heb op een recent familiefeest een gesprek gehad over fietsendragers en de zettelkast methode. Dat had ik voordien nog niet meegemaakt.

    Zo. Veel verschillende topics, maar ik heb het graag over hoe ik de stad en hier wonen ervaar, om later nog eens te lezen wat ik dacht.

    En zo krijgen jullie een beeld van hoe het hier is. Ik kan het zeker aanraden om hier eens op bezoek te komen. Mexico-stad is vooral een hele boeiende stad, en ik heb de indruk dat velen het nog niet ontdekt hebben. Als je tips zoekt, laat het zeker weten!

  • Thinking through the contour feature of Screenshot to Layout

    December 9, 2023 - Posted in build-in-public figma-plugins screenshot-to-layout

    Earlier this week I thought through the contour feature for Screenshot to Layout . This is a future feature, that essentially adds a second layer of output to the plugin, with the goal of visualizing clear shapes in the processed screenshot, so that the designer can use it as a reference point for further work.

    Right now I am thinking through how this should work by doing various experiments and prototypes.

    I’ve had the comment that my Figma plugin Screenshot to Layout is essentially “image to text”, and that is true for sure at this point in time.

    Someone else asked me: is it your goal to convert a whole screenshot to its original design? The answer to that is no. The goal is to provide designers with the ultimate starting point from a screenshot that fits into their workflow.

    The output of the Screenshot to Layout plugin should be a starting to point to continue whatever work you have to do. As a designer you will likely have a file with all kinds of attached text and colour styles as well as library components. It doesn’t make sense to try and recreate the actual layout. What makes sense is to provide a starting point that enables you to put the output into your design system faster.

    So given that, let’s look at how the contour feature would ideally work. I tweeted this to ask the community what they think:

    Given a screenshot such as this, what is the ideal output?

    Text only? Form controls visible? Buttons visible?

    left: source – right: output pic.twitter.com/KH0cqVeoY8

    — Johan Ronsse (@wolfr_2) December 2, 2023

    This screenshot shows a dialog with 4 radio buttons and 3 actual buttons.

    Personally, I think what would help me most is to see the contours of shapes that are very clear and isolated to understand a processed screenshot in a better way. In this example I would want to see the text (coming from the existing OCR features), but then from the contour feature the buttons, maybe the radio circles, but not much more.

    As an another, if you have a screenshot of a contacts list, you might want to see grey circles in the place of the actual avatars. This way you know you have to replace those with your “avatar” design system component.

    With this idea I mind I did some experimentation and wrote a script to recognize shapes in images. Specifically rectangular and circular shapes.

    The current problem I have is that this is fairly fickle. You need some exact settings to not detect text (e.g. an “o” is also a circle); in UI design there’s often overlaid elements etc. So you find that it’s easy to get to a lot of unusable output like in the screenshot below (red strokes are circles and blue strokes are “rectangles”)

    Unusable output 😅

    One can wonder in general how much can the computer “see” and how much has to be determined by the designer? The “seeing” part could potentially be enhanced by a custom machine learning model.

    Another experiment I did involved testing Microsoft’s Cognitive Services for the use case of recognising shapes, but I saw fairly quickly that this probably won’t help me.

    Microsoft Cognitive Services – Foreground matting output

    Another thing I looked into was segmentation and simplification. I think there might be something there for parts of the script, but I would have to find out where exactly it would help.

    All in all there is still lots of work to determine how to move this feature forward.

    I thought I would document these early steps in the evolution of this feature. I’ve always admired game development “devlogs” as well as for example Garret‘s blog posts about the early design decisions in Sifter. If I don’t document it now, I will surely forget.

    This is complex computer science topic which is quite new for me. If anyone has their own ideas, or feel they can offer some help, feel free to reach out!

← older
newer →
  • ©2024 Johan Ronsse
  • X
  • Mastodon
  • Portfolio 2024