h3n3/cadhub
1
0
Fork 0
Code Issues 35 Pull Requests Packages Projects Releases Wiki Activity

rough draft of UX case studies intro post. #401

Merged
franknoirot merged 3 commits from franknoirot/blog-post into main 2021-07-12 21:15:31 +02:00
Conversation 7 Commits 3 Files Changed 2 +108 -175
franknoirot commented 2021-07-06 08:19:29 +02:00 (Migrated from github.com)
Copy Link

Just opening this PR to get your edits on this intro post. I found myself going on a fair bit about why Code-CAD needs to learn from GUI-CAD and figured it would work better as its own post than as the start of the first case study.

Just opening this PR to get your edits on this intro post. I found myself going on a fair bit about why Code-CAD needs to learn from GUI-CAD and figured it would work better as its own post than as the start of the first case study.
🚀 1
Irev-Dev (Migrated from github.com) reviewed 2021-07-06 12:00:20 +02:00
Irev-Dev (Migrated from github.com) left a comment
Copy Link

Really good. I'm drawn in want to keep reading.

I'm interested to see how you'll wrap up the post if you're changing it to not include case-studies.

Really good. I'm drawn in want to keep reading. I'm interested to see how you'll wrap up the post if you're changing it to not include case-studies.
docs/blog/2021-07-04-ux-case-studies-intro.mdx
Irev-Dev (Migrated from github.com) commented 2021-07-06 11:01:52 +02:00
Copy Link

We believe that this assumption about users has fundamentally changed

I love that, it's spot on.

I think the narrative about the tools been made to cater to users of the time is very interesting. Engineering of the day was all down with drawing by draftsmen, which is why both the focus as on having these pieces of software produce technical drawing as well as why a GUI was important because there were not many programmers.

A similar story can be told for PLC, (programmable logic controllers), These are essentially industrial computers used for controlling automated lines, (think commodity production, paper, steel etc). Before PLCs, the way logic was done was with a big panels of relays. In order to sell PLC's they implemented Ladder-logic or Ladder-code, which is essentially a way of drawing the logic the same way you would draw an electric circuit if you were designing relay logic so that the same people who designed the relay panels could start programming the PLC.
image
It's clever really and nothing wrong with that direction of innovation, the problem is that PLC's still use them today!, even though the assumption about users is no longer valid (no one is learning how to design relay panels)

I'm just rifing on a thought this paragraph gave me, not trying to imply you should fit this in or anything.

One other thing I was tempted to suggest you change "We believe that this assumption about users has fundamentally changed." to "This assumption about users has fundamentally changed." to make it shorter and more assertive, but re-reading it I can see how the build up of the paragraph means "We believe" makes sense, but I wonder if maybe a question is more fitting?

That paradigm lead most of the major tools to build GUI-based systems, as they correctly assumed at the the time that the GUI offered an interface that could be understood by people in the industry. Decades have passed and the same assumption still form the foundation of the paradigm, could these assumptions have fundamentally changed?

I didn't plan on changing it that much. each time I tried to make smaller changes it was terrible, anyway just a suggestion.

> We believe that this assumption about users has fundamentally changed I love that, it's spot on. I think the narrative about the tools been made to cater to users of the time is very interesting. Engineering of the day was all down with drawing by draftsmen, which is why both the focus as on having these pieces of software produce technical drawing as well as why a GUI was important because there were not many programmers. A similar story can be told for PLC, (programmable logic controllers), These are essentially industrial computers used for controlling automated lines, (think commodity production, paper, steel etc). Before PLCs, the way logic was done was with a big panels of relays. In order to sell PLC's they implemented Ladder-logic or Ladder-code, which is essentially a way of drawing the logic the same way you would draw an electric circuit if you were designing relay logic so that the same people who designed the relay panels could start programming the PLC. ![image](https://user-images.githubusercontent.com/29681384/124572623-1f7cea80-de8c-11eb-8fb4-86c67ed1163b.png) It's clever really and nothing wrong with that direction of innovation, the problem is that PLC's still use them today!, even though the assumption about users is no longer valid (no one is learning how to design relay panels) I'm just rifing on a thought this paragraph gave me, not trying to imply you should fit this in or anything. One other thing I was tempted to suggest you change "We believe that this assumption about users has fundamentally changed." to "This assumption about users has fundamentally changed." to make it shorter and more assertive, but re-reading it I can see how the build up of the paragraph means "We believe" makes sense, but I wonder if maybe a question is more fitting? > That paradigm lead most of the major tools to build GUI-based systems, as they correctly assumed at the the time that the GUI offered an interface that could be understood by people in the industry. Decades have passed and the same assumption still form the foundation of the paradigm, could these assumptions have fundamentally changed? I didn't plan on changing it that much. each time I tried to make smaller changes it was terrible, anyway just a suggestion.
docs/blog/2021-07-04-ux-case-studies-intro.mdx
@@ -0,0 +14,4 @@
I'm helping CadHub out by designing the interfaces for the [new editor](https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/CadHub?node-id=1114%3A1608), [project viewer](https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/?node-id=1046%3A0), and [more](https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/?node-id=1150%3A1618). Right now we're focused on getting the Code-CAD user experience perfected so that users can try out all the great Code-CAD packages out there in a simple and sharable way. But we think that the future of Code-CAD will pull UX lessons from traditional, GUI-based CAD systems. So I'll be taking a look at the history and UX of some of today's CAD tools to see how we might bring them along with the Code-CAD evolution.
<!--truncate-->
Irev-Dev (Migrated from github.com) commented 2021-07-06 11:05:27 +02:00
Copy Link

Nice, easy to forget about adding this somewhere. :)

Nice, easy to forget about adding this somewhere. :)
franknoirot (Migrated from github.com) reviewed 2021-07-06 16:20:29 +02:00
docs/blog/2021-07-04-ux-case-studies-intro.mdx
@@ -0,0 +14,4 @@
I'm helping CadHub out by designing the interfaces for the [new editor](https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/CadHub?node-id=1114%3A1608), [project viewer](https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/?node-id=1046%3A0), and [more](https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/?node-id=1150%3A1618). Right now we're focused on getting the Code-CAD user experience perfected so that users can try out all the great Code-CAD packages out there in a simple and sharable way. But we think that the future of Code-CAD will pull UX lessons from traditional, GUI-based CAD systems. So I'll be taking a look at the history and UX of some of today's CAD tools to see how we might bring them along with the Code-CAD evolution.
<!--truncate-->
franknoirot (Migrated from github.com) commented 2021-07-06 16:20:29 +02:00
Copy Link

Definitely, I just started with the truncate on my blank post to write around it.

Definitely, I just started with the `truncate` on my blank post to write around it.
franknoirot (Migrated from github.com) reviewed 2021-07-06 16:24:01 +02:00
docs/blog/2021-07-04-ux-case-studies-intro.mdx
franknoirot (Migrated from github.com) commented 2021-07-06 16:24:01 +02:00
Copy Link

Totally! My stepdad runs a local machine shop and I was surprised to see their interfaces still feel like 80s CLI-style interaction with the machine. So wild how a new technology will come out, and in the course of adopting it, people will use metaphors they understand to determine its interface as a stop-gap, but that stop-gap can like atrophy into the way things are done for far longer than users need the metaphor.

Dig the edit, just tweaked two things and made the replacement.

Totally! My stepdad runs a local machine shop and I was surprised to see their interfaces still feel like 80s CLI-style interaction with the machine. So wild how a new technology will come out, and in the course of adopting it, people will use metaphors they understand to determine its interface as a stop-gap, but that stop-gap can like atrophy into the way things are done for far longer than users need the metaphor. Dig the edit, just tweaked two things and made the replacement.
Irev-Dev (Migrated from github.com) reviewed 2021-07-12 10:43:09 +02:00
docs/blog/2021-07-04-ux-case-studies-intro.mdx
@@ -0,0 +1,43 @@
---
slug: ux-studies-intro
Irev-Dev (Migrated from github.com) commented 2021-07-12 10:43:08 +02:00
Copy Link

Sorry that I can't remember, if you were planning on adding to this to make it a long form, or if the case-studies will be seperate posts?

I'm asking here because maybe a slug of just ux-studies might give you flexibility later on as it doesn't imply a series, but you could still do ux-studies-part2 etc later on. I'm only saying this because changing the title and the content later is fine, but we don't want to change the slug after publish.

But than again, if you've decided hard on a series, that cool and no need to change it.

Sorry that I can't remember, if you were planning on adding to this to make it a long form, or if the case-studies will be seperate posts? I'm asking here because maybe a slug of just `ux-studies` might give you flexibility later on as it doesn't imply a series, but you could still do `ux-studies-part2` etc later on. I'm only saying this because changing the title and the content later is fine, but we don't want to change the slug after publish. But than again, if you've decided hard on a series, that cool and no need to change it.
Irev-Dev commented 2021-07-12 10:45:38 +02:00 (Migrated from github.com)
Copy Link

Sweet, just give the word if you're ready for me to merge and publish?

Sweet, just give the word if you're ready for me to merge and publish?
Irev-Dev (Migrated from github.com) approved these changes 2021-07-12 10:45:50 +02:00
franknoirot commented 2021-07-12 19:14:52 +02:00 (Migrated from github.com)
Copy Link

@Irev-Dev yup I'm set for merge & publish when you are!

@Irev-Dev yup I'm set for merge & publish when you are!
❤️ 1
Sign in to join this conversation.
Reviewers
No Reviewers
franknoirot
Irev-Dev
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
h3n3
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: h3n3/cadhub#401
Delete Branch "franknoirot/blog-post"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?