Interesting! So if you wanted to integrate it with your own custom design system (components & CSS), could you define a bunch of mappings somewhere between visual actions (dragging edges to resize etc) and corresponding changes to the elements/attributes in the code? Also - what frontend frameworks does/will it work with?

I wanted to do a similar-ish thing to do with creating diagrams in Svelte, where you could drag boxes to reposition them - with some way of doing the drag within the browser and having it talk to your editor somehow, so no dedicated design tool involved - but the thing of mapping the drag action to a change to a particular syntax node seemed a bit too complex to just "knock together" something like that

We're still working out how to support the early stage ideation design work where free flow layout is likely the best interaction. Our initial focus is on using design systems with a well built set of foundational primitives and layout components that you can use like Lego blocks. Both Chakra UI and Braid DS support this way of working quite nicely.

Currently we support React projects written with TypeScript.

ux designer might perceive this is for developer, developer might perceive this is for ux designer. Design should be cheaper to change than real frontend code, because it is under-specified, with lots of details omitted. If the design is the frontend code, can we still sit beside the designers desk to iterate prototype fast?

There is a wide spectrum of types of design work, spanning for very early ideation + visual design and all the way to interaction design with pre-existing design system components. We're currently adding most value later in the process, but we are also looking at supporting earlier stages with freeform layout (e.g. absolute position and dragging to reposition) to allow designers to just "throw something on the canvas in an unstructured way until it feels right". That "something" can be quite low level primitives like Box and Text components, that can provide some of the same freedoms that rect and text does today in Figma for example.

On fast prototyping, one of the strengths we have there is to allow the use of production components right next to whatever new the designer is working on (e.g using a combination of Box and Text). So you can get a much better sense of the real product, while also allowing for creative freedom (which then needs to be turned into production components with tests being written by devs).

Can you design components that vary their visual appearance depending on the state or the input data with Henosia?

Paul Sonnentag We've done early explorations in this area, but nothing that we can share widely yet. Since our source of truth is TypeScript code (as an AST) we can reason about the flow of React props and conditional rendering of elements/class names. The challenge is to provide a meaningful UI for a designer based on what's essentially open-ended TypeScript code. Same as the TypeScript compiler does flow analysis, there may be cases where code is too difficult to follow for the tool (which we would then tell the user), but there may be an 80/20 rule in there where just giving designers a bit of conditionals would add a lot of value.

The 80/20 rule will get you a long way. When code is too difficult for a good tool to follow, either (1) the code is bad, or (2) it's implementing some higher order pattern that uses a different mental model than the flow that the abstraction layer ends up producing.

Rails filters come immediately to mind as an example of (2). guides.rubyonrails.org/action_controller_overview.html#filters The mental model is pretty simple, but the control flow that leads to their execution is pretty much inscrutable.

Good points. I've been thinking lately that high quality UI component code should be easy to explain to a non-technical designer if they asked how a component works. If code meets that quality bar, a tool has a chance at visualizing it in a way where the designer can feel safe enough to edit the visual parts.

By "explain" I don't mean syntax specifics or technical jargon, more like data flow, i.e. "this todo list component repeats a todo item component for each todo in the list it is displaying. To each todo item component we pass in the todo data which includes the todo title and whether the todo is completed".

twitter.com/whitebox_sys/status/1528796270797651968

Basically it is meant to be a more humane and flexible version of graph databases like Neo4j. The "database" is currently text files with a git-like design that looks for changes and updates hands off indexes that are used for the queries (stored separately under a single .bha folder).

Ultimately I would like it to ship with a large "standard library", that doesn't just search for your own entities, but extracts them from known file types (probably using Apache Tika). So it would be like plugging a super-powered graph search engine onto your normal OS.

For example, if you had an Excel file, it would add Entities in your graph, not just at the file level, but also things within it. Like it would automatically make;

@[C:\Users\Chris\my excel file.xls]

   ![MS Excel Workbook]

   #created:01/03/2019  #filesize:120kb

   #worksheet: @[Sheet 1]

   #worksheet: @[Sheet 2]

   #worksheet: @[Sheet 3]

I think a system like this could be used to create the Itemized OS that Alexander Obenauer writes about, on top of the OSes that we already have.

I love how this is riffing on a question in this forum. #collaboration

The order of the tags in queries is significant, right? Like the difference between asking who is the brother of Bart vs whose brother is Bart. I wonder if including explicit query variables like Prolog does will make the queries easier to read/learn, even if more verbose. It might also give you more room for maneuver in adding more features.

There's actually a colon that distinguishes the "with the value of" case, but yeah I think you would eventually want named variables in queries, for some more complicated patterns. SPARQ uses ?var notation for this which actually fits with the rest of the syntax neatly.

I was planning to use something like this for the functional calculation side, like;

@Chris

  !Person

  #email:chris@chris.com

  #email:chris@other.com

  #sent-emails:?[Chris's sent emails]



?[Chris's sent emails]

  !Email     <- filter to !Email's

  ?[Chris email address] = @Chris #email

  #from:?[Chris email address] <-- filter using var



?[Chris email recipients]

  ?addr = ?[Chris's sent emails] #to

  #email: ?addr

I haven't really thought it through properly, I just wanted to actually try out some of the things I had been discussing in the mentioned threads

If you decide to create a new surface syntax for what are essentially RDF triples, you might want to make sure your model is compatible with RDF so you can interoperate with other knowledge bases.

For some prior art in terms of the syntax itself, check out the rather similar Turtle notation:

@prefix : <[example.org/elements](http://example.org/elements)> .                                                                              

<[en.wikipedia.org/wiki/Helium](http://en.wikipedia.org/wiki/Helium)>                                                                                  

    :atomicNumber 2 ;               # xsd:integer                                                                      

    :atomicMass 4.002602 ;          # xsd:decimal                                                                      

    :specificGravity 1.663E-4 .     # xsd:double

It does essentially get compiled to triples under the hood, because it currently is implemented on top of Neo4j, but the queries are bewilderingly complex when expressed in those terms.

For example;

#sibling: @Bart

Is translated to the following Cypher query (it would be similar in SPARQL);

match (v_: Entity {{name:"Bart"}})

    match p_v = ((v:Entity)-[:IMPLIES*0..]->(v_))

    with distinct v, [m in nodes(p_v) where 'Context' in labels(m)] as contexts

    match (k_:Attribute {name:"sibling"})

    match p_k = ((k:Attribute)-[:IMPLIES*0..]->(k_))

    with distinct v, k, [m in nodes(p_k) where 'Context' in labels(m)]+contexts as contexts

    match (k)-[:VALUE]->(c:Context)-[:VALUE]->(v),

                        (c)-[:CONTEXT]->(n:Entity)

    with distinct n, contexts

    where size(contexts) = 0 or 

    all(c in contexts where exists((c)-[:CONTEXT]->()<-[:IMPLIES*0..]-()<-[:CATEGORY|ATTRIBUTE*0..1]-()<-[:IMPLIES*0..]-(n)))

     

    return distinct n

Which is not reasonable for a user to write.

I'm on a bit of an "ethnographic" thing at the moment so trying to come at stuff from a starting point of how people are already interacting with computers right now in the real world, rather than my own preferences which tend to be far too mathematical, "precise" and "elegant" for most of the species 🙃

Interesting! A small-scale knowledge graph with a lightweight interface looks very useful indeed.

From my first impressions, I'd say yours is already getting too complex. Example: the way you disambiguate "Bart" by context. For a personal knowledge database, I'd probably prefer to keep entities unique, implying longer names, and add a completion interface for discovery and for faster entry. You'd type "Bart" and the system proposes all the entities containing "Bart" for selection.

Yeah for sure you would need autocomplete in an actual system.

To clarify the underlying model, @Bart and @[Bart Simpson] are separate entities, marking it as synonymous just allows them to be switched in/out in a query. This was meant to be like Wikipedia titles. The canonical title will be something globally unique like "Queen Victoria (British monarch)", "Victoria (Australian state)", but will typically be referred to by a name ("Victoria") which is only contextually unique. This was my attempt to reflect how humans use names, but without introducing too much "magic" on the computer side.

A dumb example that might be more clearer of the point of this feature;

@[My front door]

   !Door

   #closed



@[My garden door]

   !Door

   #not-open



@[Half open interval [0, 1)]

   ![Subset of the Reals]

   #not-open #not-closed



!Door

   #not-open = #closed

Then the query #closed with return the two doors, but not the set, because the rule #not-open = #closed does not apply in the context of !Set , only !Door .

Neo4J is worse at this sort of thing than a TripleStore would be. In terms of making this query in SPARQL (using my Clojure wrapper):

(query `{:select [?siblingLabel]

         :where  [[~(entity "Bart Simpson") ~(wdt :sibling) ?sibling]]})

;;=>

[{:siblingLabel "Lisa Simpson"}

 {:siblingLabel "Maggie Simpson"}

 {:siblingLabel "Hugo Simpson"}]

My own note-taking system includes a bunch of semantic web/GOFAI stuff, but also uses neural nets, &c. I strongly encourage this line of inquiry! 🙂 But I also wanted to give you some advice from farther down this road.

But how does it know that "Bart Simpson", sibling, "Lisa Simpson"?

The actual triple is "Bart Simpson", sister , "Lisa Simpson"

I actually had Hugo in the demo originally but I thought it would confuse people with deficit Simpsons knowledge 🤣

Jack Rusher I'm curious to hear more about how you use symbolic AI in your note taking system!

Chris Knott In this case the database happens to contain those assertions, as I'm running this query against Wikidata. If I had a DB with only brother and sister, I'd be able to specify what sibling means using a meta-language that would then allow this query to remain as simple.

Kartik Agaram I need to make a video about the whole thing

And here’s the code: github.com/tobyshooters/livepipe/tree/main/spaces

Do you notice a difference in remembering "where things are"?

Not quite sure yet in any general sense. While programming it I found that I quickly associated a chair with where the program was running. It was frustrating at first, but eventually just became expected.

This report is a very accessible place to start chewing into what the research has to say about teaching and learning programming. I've really enjoyed using it as a gateway with colleagues who are involved in communicating programming concepts in various ways but haven't formally trained in pedagogy

Just want to say, I think this is great! Glad to see you doing this 🙂

Thanks Jimmy, I appreciate that! Hoping I’ll see some folks from this community in the applications 🙂

Nice! This is my first contact with the term "egui" — what does it mean?

egui is an amazing library for backend-agnostic widget rendering written in Rust.

egui is amazing for easy to use, customizable, and nice performance.

egui.rs

Wow, that's an impressive looking library.

Yes, I believe this has a potential to be used everywhere in the near future.

That is very cool @Ryo Hirayama. Can you annotate the wires?

Yes! The next TODO is a custom look of ports, plugs, and cables, and it can be done soon.

Nice. I think there's probably a sort of nested box, node and wire approach that could be used for expressing declarative rules, which would interesting to prototype as an alternative to the method we are using now.

I don't get your point. Do you have any example of "a sort of nested box, node and wire approach" and "declarative rules"?

I will attempt to draw a picture when I get a chance.

Thanks

Interesting concept. It looked very accurate in the example I checked.

Have you given any thought to liability, i.e. Codeball automatically merges a PR that goes on to do damage, be it physical and/or economic? I assume you'd have to be super clear on how to define your terms of service and make sure that your company insurance is fully up to par.