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
- 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
- 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
- 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
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
- 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
- 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)
- 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
- 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:
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!
-
Planning for Screenshot to Layout 1.2
- Posted in build-in-public figma-plugins screenshot-to-layout
I am doing an investment in taking Screenshot to Layout to to the next level. I am working together with a few freelancers, each skilled in their own right, from making plugins for graphic design apps to advanced Javascript wizardry. Together we will improve the plugin.
Here’s a sketch of what I am to achieve with the new marketing website. Showing the idea in a nice GIF/short video/animation will be a challenge. I want to write a bit of a “devlog” so I don’t forget what we are doing. Maybe it’s bad luck to talk about your plans, but OK. I am trying to build in public, and I found that that I didn’t write down enough while doing Obra Icons.
Right now we are in a planning phase where I am setting milestones and attaching min/max budgets to these milestones.
- First, we will lightly research alternate solutions. Is the Azure platform the perfect platform to keep building on? Should we use Tesseract? Or something else? I am pretty sure we will keep building on Azure, but it feels like the right time to assess – with the knowledge of the team at hand – what alternate solution can be found
- A very senior programmer friend I’ve known for a looooong time will likely take a close look and use his 30+ years of programming experience to asses the above.
- Next, we will do 2 parallel tracks: the first track is to improve the algorithm behind STL. What I call the “algo” actually consists of 2 parts.
- The first is what output is gained from “the machine”. Microsoft has a computer vision API, which, given an image with text, gives you back the coordinates of said text and information about what it detected as lines, words or paragraphs. The output of this is sometimes pretty good and sometimes has problems, so there is code that has to work around those problems.
- A reason to stay with Microsoft Azure is that Azure makes an update to their engine every 6 months. A quick test of the latest model (31-10-23) is promising.
- The second part is the code that processes said text + coords information to the canvas. That code takes the raw information and tries to make sense of it. For example, if the bounding box of a line of text spans 20px between y1 and y2, and it’s only detected as a single line of text (no paragraphs), there is a likelihood that it should be rendered back to the canvas as 16px text. If it’s a paragraph, the calculation is a little bit different, because now we are also taking into account space between lines.
- What kind of improvements can we make then? I will be the first to say that the code that I wrote myself is not very good. It works, and I am quite proud of it (its even in TypeScript!), but my hope is that a second look by a skilled development team will bring the code to a new level, also enhancing the OCR output. Right now, there are various small problems which I discuss in detail in this video. To spare you the watch, they are a) inaccurate positioning b) inaccurate text sizing of text layers that look similar in the source screenshots c) the recognition engine mistaking typical icon shapes as single characters (o, v, > etc) and d) the system not at all working with vertically oriented text (90 degree rotated text)
- The first is what output is gained from “the machine”. Microsoft has a computer vision API, which, given an image with text, gives you back the coordinates of said text and information about what it detected as lines, words or paragraphs. The output of this is sometimes pretty good and sometimes has problems, so there is code that has to work around those problems.
- The other track is about bringing the plugin to be a full inside-Figma experience. Right now, you have to register on an external website, and the process feels a bit disjointed. Ideally, you can trial the plugin without having to register at all, and then register if you use it a lot. I still want to keep that logic to track people’s usage and so my cloud bill does not go overboard.
- When we have combined these two tracks, we need to get the word out about the plugin to more people. The third track is a small marketing track which involves improving the visual design of the website, promoting the idea to our combined network and possibly the creation of a clear demo/marketing video.
This is the plan for a first phase of the plugin development, which is slated for release in +-3 months. In the meantime, you can already try out the current version of the plugin for free. It will be free for at least the next full year, so make sure to give it a try. It’s here on Figma community.
- First, we will lightly research alternate solutions. Is the Azure platform the perfect platform to keep building on? Should we use Tesseract? Or something else? I am pretty sure we will keep building on Azure, but it feels like the right time to assess – with the knowledge of the team at hand – what alternate solution can be found
