Hi fellow FoC community folks! You probably know me from.. well.. being the moderator here, doing the podcast, maybe from Twitter. I'm going to put on a different scarf today. I'm looking to hire someone. I work for a little company based in western Canada that builds interactive multimedia tools & simulations. You can imagine emoji sparkles interposed between those 1990s buzzwords if you like. The team is 7 artists, 3 subject matter experts, 1 programmer (hi), and a few other folks for admin and such. My job is to build tools for the artists, who make multimedia for the subject matter experts, who use it to teach people around the world about mind-blowingly complex machines. We're tiny compared to the audience we serve (from high-school students up to terrifying multinationals), but we've got an unbelievable reputation in our corner of the world for being like 20 years ahead of the competition. It's a weird company. I love it. You might know I've been working on a project called Hest. It's an attempt to take some of the work we do on visualizing complex systems, and apply it to node-wire visual programming. Well, I'm looking for someone to come help me work on a complementary project — building a new drawing tool for the artists on my team. They currently do their drawings in Adobe Animate (because we used to use Flash, because the 2000s were a beautiful time for multimedia and we're not even close to recapturing that culturally or technologically). They export their drawings as SVG files, and then bring them to life using some JS animation/simulation frameworks I wrote for them. There's a problem: "export their drawings as SVG files". An SVG is a great container for a vector image. It's an awful container, especially when generated by a general-purpose drawing app like Adobe Animate, for rich semantic information about what the artist means for their drawing to represent, especially when the drawing is a very specific kind of technical illustration. So here's the plan: We'd like to design and prototype a new drawing tool. Something like OmniGraffle, but much simpler. There'd be some sort of library of common symbols, which you could drag and drop onto a canvas, and then wire together with a few different kinds of path drawing tools. Finally, the program could (perhaps) export a much richer SVG with a bunch of metadata that preserves various aspects of the intent behind the drawing. (I say "perhaps" because there's a lot of different approaches that could be taken, and making that decision would be part of the R&D process). Once this drawing tool exists, the goal is to push it in the direction of being a tool for programming said drawings. We already have a simulation toolkit that works with SVG graphics that the artists know well, but there's so much more we could do by giving them live / visual programming that happens right in same tool as their drawing canvas, not some detached build->run->debug process with a text editor like they have today. And whereas the goal with Hest was to start with the programming experience and build "down" toward a usable tool for dynamic drawings, the goal for this new project is to start with a usable drawing tool and build "up" toward making those drawings dynamic. This is already a wall of text, but I'll share one more bit of detail that should be a helpful filtering function for folks who might be interested in this project. This is planned to be a 3 month contract position where you'll do some initial R&D work and build as much of a prototype as you can — a way to get the ball rolling, and then hand it off to me (or possibly yourself if we extend/renew the contract). The pay is also competitive for Canada, where we're based, but not what you might be used to if you're from a hotspot in the US — $2000/week USD. If you have questions about this, please crack open a thread here and ask them. Ask anything, I'm very interested in being transparent about all details of this. Finally, here's a page on our website where you can get a quick summary of who we are, watch a video of simulations we've made, and read a slightly less wall-of-text description of the position at the bottom (it's the 3rd job listed, the one about an interactive drawing tool). The position is open now, I'm setting up calls ASAP, so if you're interested by all means let me know! <3

Hi, I'm sure there are a lot of details to sort out. I actually am building a drawing component in Rust to mirror Visio/Figma that then uses WebAssembly to render to canvas. I've made a ton of WYSIWYG editors over the years. It's part of my Adama Platform as the second leg of a board game IDE / super tool ( https://www.adama-platform.com/2022/02/24/open-strategy.html ). I intend to make the core of it open source. I'm still debating if I make the editor open source or not. I can prioritize a live demo of what I've got. Let me know if you are curious, and I migrate it from my old client to the new client (I had it working a few months ago, but then I decided to build my infrastructure into a SaaS, and I have yet to migrate it to using the new auth and API) There may be an interesting synergy here to get you cracking faster and help drive both efforts.

Not something I'd be able to help with, but just let me say how awesome this product is, and how glad I am that this is happening in Red Deer! #C01BKSG4ZFT for the win. (i'm in sherwood park)

Hi @Jeffrey M Barber. Yeah, the tool we're hiring for would have many of the same core components as something like a board game editor. A rendering surface, a scene graph, some sort of coordinate system / matrix math to render things in the right place (though possibly just handled by SVG if that ends up being the rendering API used — to be determined). I think Rust would be a no-go for us, just because I'd have to maintain it and I don't know Rust (though I'd love to learn it, I just don't want to sign myself up for that on a deadline, haha). That stuff I listed — scene graph, rendering, etc — that stuff is all fairly easy to set up in my experience (especially if you're happy leaning on the browser). The tricker parts are what you build on top of that, especially when it comes to GUI interactions and making them good feeling, reliable, etc.

So, if I understand correctly, this drawing tool would be used only from a web browser? Or would there be an application for creating the drawings?

I figure it'd be an Electron app, but developing for the browser is fine too (I can always wrap it up in Electron later). Web tech for sure, though — all our existing media is built atop the web platform.

Maybe a bit offensive of a question, but do I need web experience for this job or can I learn this Electron thing in a week, if I have solid design and C++ programming skills?

@Dolf For this position, the things I'd expect an applicant to be familiar with are a large subset of the details for each of the following: • How to design and build canvas-centric GUIs that feel good • Any of the core web graphic APIs — SVG, 2d canvas, WebGL — and how to maintain 60fps when using them on complex scenes • JavasScript, TypeScript, CoffeeScript or some other similar-to-JS (not WASM) language If you know the above, you can pick up Electron in a half-day. But the above, while not strictly web-specific, is a little more demanding to pick up. To consider someone for this position who didn't have experience working with web tech, I'd need to see a really solid portfolio of past work that showed they could do well when asked to work with the above.

Ok, thanks. I guess this is not for me then.

Have you looked at tldraw?

@Vijay Chakravarthy — I sure have. @Francois Laberge even encouraged me to consider building this tool atop it. I think there's wisdom in this, so I think it'll be worth exploring as an option in the initial phase of this project.

Sharing more broadly, I've isolated my 2D editing component from my board game suite (as I'm cleaning it up for my own sanity), and I put a demo of the newly minted tool: http://ide.adama-platform.com/solo/ It's primary concern right now is the management of boxes, and I'm going to be filling in the boxes with various things and adding lines/paths.

Interesting project. I took a look at your public repos, with the concepts of Take, Make, Symbols and Scopes it seems like you're already half way to a DSL. To get to your goals around liveness you might just need to go the whole way. It strikes me as more of a data modeling problem with the drawing being a bit incidental. In the examples I saw, the number of elements and state doesn't grow too large so I could envision modeling it as an in-memory triple store with arbitrary indexes and custom update verbs. It's also adjacent to my own FoC activities where I've been looking at reactivity from the point of view of making more sophisticated database indexes. If any of that strikes a chord I'd be interested in taking on the project.

Hi I have ton of exp as developer. Handled complex projects successfully. For more than 17 years now. Worked on vanilla JS and JQuery a lot. I know basics of WegGL and as I started my programming life a s a game programmer, I used to have (still somewhat) a solid grasp over OpenGL, Shaders, Game Engine etc. I have looked into WebGL to some extent. Even a bit into WebGPU. I have a full time job, unless you guys are looking for someone full time, and if you think to start with 10-12 hours per week can make the cut, I will be very interested.

@Alex Thompson — Thanks for taking a look! Yes, the programming libraries for our simulations are quite DSL-like. Indeed, going all the way to a richer programming interface is an eventual goal — that shared goal is why we're all here, right? The drawing interface is the problem we need to solve first. Once we have a richer interface for drawing, we can build a programming interface in terms of it. Here's an example that should demonstrate why the drawing interface matters. Imagine an electrical circuit schematic. One of the things we do with our electrical circuit simulations is animate little arrows that flow through the circuit to depict the flow of electricity. For these arrows to correctly flow through the circuit, they need to know the visual structure of the circuit — which paths are connected to which other paths, where those connections are, the shape of all paths (sometimes they're curved), the speed and direction of flow on each path, etc. The structure of the circuit is fully expressed by the artist when they make the drawing — it's inherent to the visual representation. If two lines touch (usually with a little dot at the intersection), they're electrically connected. But because the artist is using a general purpose vector graphics app, this information about connectivity isn't captured. It's implied through the drawing, but it's not reified in data. I have to recover this connectivity information by having the artist draw a second version of the circuit (a simplified representation without visual details like intersection dots — sort of like a physics mesh in a video game). This is fed into a system that rebuilds the structure of the circuit using heuristics. Finally, the artist has to write some code to specify the speed and direction of flow on every path within the circuit. Instead of a general purpose vector graphics app with a "path" tool, we need a special purpose simulation drawing app with an "electrical path" tool. When drawing electrical paths, the app will know to capture an internal representation of the connectivity structure. But it doesn't just have to be about capture — the app can show actual arrows representing how electricity will flow through the circuit drawing as the artist is drawing it. Immediate feedback, with direct manipulation controls for tuning that behaviour. Hopefully that clarifies things. Thanks again for taking a look at what we're doing!

@Ivan Reese Sorry I wasn't trying to downplay the drawing part. I was just thinking out loud about the data part. The above clarification helps a lot. I'll respond further in DM