7 ms·

Devcards – Taking Interactivity to the Next Level

105 points by brucehauman 12y ago

damienhoffman 12y ago
This is awesome, Bruce. Looks like you were up before Apple! So, what are your plans?
ezisezis 12y ago
Ever since I first talked to Bruce about this(and other Om/React users), I've thought that this type of approach could lend itself really well to visual image based regression testing. The other cool thing is that with Om you can serialize record Om state transactions. By doing this you could see how people are using specific components. Perhaps you could cycle through the last 10 users or the 10 most common interaction patterns of a component and view those interactions on a card. This could be a boon to interaction designers looking to see how people are using disparate components/pages within an application.
- ezisezis 12y ago
  To expound on this, what about having cards, ie single components, be linked to a graphical/interaction test CI-suite. I know this is sort of pie in the sky but it gets me thinking.
  - brucehauman 12y ago
    Actually, that's not pie in the sky, running selenium against a set of cards would work great. And may be an easier env to work in than the actual main app.
wukkuan 12y ago
This is great work. The video in particular sold the idea to me. Projects like this are really making me want to build something substantial in ClojureScript.
jzwolak 12y ago
Yeah, the coincidence with Apple's release of swift and playground is eerie! But this is opensource and for Clojure! Oh man, that's exciting!
damienhoffman 12y ago
opensource = awesome alternative to Playground.
nathanbatson 12y ago
I love this visual approach for testing and debugging frontend interactions.
drcode 12y ago
This approach has a lot of appeal- I am building lots of Om components that change over time, and things that change over time are hard to debug. With this approach, I could put in different devcards for snapshots in time for my components, and debug those in a static manner, and see them all in front of me at the same time. The one additional feature I'd like to see (or maybe it exists already, I just looked at the project briefly so far) is to have a single Om appstate that mutates over time, going from card to card. Then, if I want to document/debug an action by the user requiring multiple steps, I could see each intermediary in the chain of actions. (i.e. "If the user clicks here, they see this. If they now type this here, they see this.")
- brucehauman 12y ago
  I have been working towards that. If you are still following the queue of messages that you mentioned a while back, then you could supply each card instance of your "program" with the list of messages that you need to get to the state you need. So you could make a loop to create the list of cards you want to look at.
  - drcode 12y ago
    I think I might make devcards part of my regular workflow. It seems obvious now, seeing devcards, that the ease with which Om/React can render "snapshots" makes this the most sensible way to develop for Om.
    - brucehauman 12y ago
      I'd love to hear what your experience is and/or see examples.
KingMob 12y ago
Bruce, how does this compare with Chris Granger's plans for Aurora? And, have you considered making this a Light Table plugin?
- brucehauman 12y ago
  I have only seen Chris's Strange Loop presentation. So I don't know much about his plans for Aurora. I do agree that the time is ripe for a visual programming language built in the browser. I haven't looked into LT integration just yet. But I am open to that of course. Sounds like an absolutely great idea. Devcards is still super new. And I hoping that people really think about what this means in their particular workflows and hopefully reintegrate knowledge back into Devcards.
  - KingMob 12y ago
    Cool, thanks for making this, I'm going to try to check it out soon. BTW, I assume you've seen Bret Victor's talks, but if not, you absolutely must, especially Inventing on Principle.
Tcepsa 12y ago
Mind. Blown. Time for me to get serious about learning ClojureScript ^_^ Thanks for putting this together; it's amazing!
- brucehauman 12y ago
  Really glad you liked it.
e12e 12y ago
Looks nice. Any particular reason why this isn't packaged so that it works offline? (Ie: bundle up css/js resources)?
- brucehauman 12y ago
  You're talking about the leinigen template? I just don't like the current situation for distributing these resources. I figure if you want, you can always download and store these resources locally if you want.
dkersten 12y ago
This is really cool. Going to look at integrating this into my Clojurescript/Om development workflow.
- brucehauman 12y ago
  Let me know how it goes. I'm still trying to figure this out https://github.com/bhauman/devcards#what-do-i-do-for-deployment https://github.com/bhauman/devcards#what-do-i-do-for-deploym...
  - dkersten 12y ago
    Sure, will do. I was actually looking at that just before I posted. My initial thought (before seeing your FAQ) was a no-op compile, but you rightly point out that this may not be the best approach due to littering the production code. I will probably go the separate devcards files route and have the production profile exclude these. Maybe src/ test/ and devcards/ ? But I'll experiment with it and see what works best for me and let you know.

105 points by brucehauman 12y ago

This is awesome, Bruce. Looks like you were up before Apple! So, what are your plans?

Ever since I first talked to Bruce about this(and other Om/React users), I've thought that this type of approach could lend itself really well to visual image based regression testing. The other cool thing is that with Om you can serialize record Om state transactions. By doing this you could see how people are using specific components. Perhaps you could cycle through the last 10 users or the 10 most common interaction patterns of a component and view those interactions on a card. This could be a boon to interaction designers looking to see how people are using disparate components/pages within an application.

ezisezis 12y ago
To expound on this, what about having cards, ie single components, be linked to a graphical/interaction test CI-suite. I know this is sort of pie in the sky but it gets me thinking.
- brucehauman 12y ago
  Actually, that's not pie in the sky, running selenium against a set of cards would work great. And may be an easier env to work in than the actual main app.

wukkuan 12y ago

This is great work. The video in particular sold the idea to me. Projects like this are really making me want to build something substantial in ClojureScript.

jzwolak 12y ago

Yeah, the coincidence with Apple's release of swift and playground is eerie! But this is opensource and for Clojure! Oh man, that's exciting!

damienhoffman 12y ago

opensource = awesome alternative to Playground.

nathanbatson 12y ago

I love this visual approach for testing and debugging frontend interactions.

drcode 12y ago

This approach has a lot of appeal- I am building lots of Om components that change over time, and things that change over time are hard to debug. With this approach, I could put in different devcards for snapshots in time for my components, and debug those in a static manner, and see them all in front of me at the same time. The one additional feature I'd like to see (or maybe it exists already, I just looked at the project briefly so far) is to have a single Om appstate that mutates over time, going from card to card. Then, if I want to document/debug an action by the user requiring multiple steps, I could see each intermediary in the chain of actions. (i.e. "If the user clicks here, they see this. If they now type this here, they see this.")

brucehauman 12y ago
I have been working towards that. If you are still following the queue of messages that you mentioned a while back, then you could supply each card instance of your "program" with the list of messages that you need to get to the state you need. So you could make a loop to create the list of cards you want to look at.
- drcode 12y ago
  I think I might make devcards part of my regular workflow. It seems obvious now, seeing devcards, that the ease with which Om/React can render "snapshots" makes this the most sensible way to develop for Om.
  - brucehauman 12y ago
    I'd love to hear what your experience is and/or see examples.

KingMob 12y ago

Bruce, how does this compare with Chris Granger's plans for Aurora? And, have you considered making this a Light Table plugin?

brucehauman 12y ago
I have only seen Chris's Strange Loop presentation. So I don't know much about his plans for Aurora. I do agree that the time is ripe for a visual programming language built in the browser. I haven't looked into LT integration just yet. But I am open to that of course. Sounds like an absolutely great idea. Devcards is still super new. And I hoping that people really think about what this means in their particular workflows and hopefully reintegrate knowledge back into Devcards.
- KingMob 12y ago
  Cool, thanks for making this, I'm going to try to check it out soon. BTW, I assume you've seen Bret Victor's talks, but if not, you absolutely must, especially Inventing on Principle.

Tcepsa 12y ago

Mind. Blown. Time for me to get serious about learning ClojureScript ^_^ Thanks for putting this together; it's amazing!

brucehauman 12y ago
Really glad you liked it.

e12e 12y ago

Looks nice. Any particular reason why this isn't packaged so that it works offline? (Ie: bundle up css/js resources)?

brucehauman 12y ago
You're talking about the leinigen template? I just don't like the current situation for distributing these resources. I figure if you want, you can always download and store these resources locally if you want.

dkersten 12y ago

This is really cool. Going to look at integrating this into my Clojurescript/Om development workflow.

brucehauman 12y ago
Let me know how it goes. I'm still trying to figure this out https://github.com/bhauman/devcards#what-do-i-do-for-deployment https://github.com/bhauman/devcards#what-do-i-do-for-deploym...
- dkersten 12y ago
  Sure, will do. I was actually looking at that just before I posted. My initial thought (before seeing your FAQ) was a no-op compile, but you rightly point out that this may not be the best approach due to littering the production code. I will probably go the separate devcards files route and have the production profile exclude these. Maybe src/ test/ and devcards/ ? But I'll experiment with it and see what works best for me and let you know.