Devcards – Taking Interactivity to the Next Level
rigsomelight.com
Devcards – Taking Interactivity to the Next Level
1–10 of 23 posts
Re: Devcards – Taking Interactivity to the Next Level
#2This is awesome, Bruce. Looks like you were up before Apple!
So, what are your plans?
Re: Devcards – Taking Interactivity to the Next Level
#3Ever 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.
Re: Devcards – Taking Interactivity to the Next Level
#4This 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.
Re: Devcards – Taking Interactivity to the Next Level
#5Yeah, the coincidence with Apple's release of swift and playground is eerie! But this is opensource and for Clojure! Oh man, that's exciting!
Re: Devcards – Taking Interactivity to the Next Level
#6opensource = awesome alternative to Playground.
Re: Devcards – Taking Interactivity to the Next Level
#7I love this visual approach for testing and debugging frontend interactions.
Re: Devcards – Taking Interactivity to the Next Level
#8Ever 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 interact…
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.
Re: Devcards – Taking Interactivity to the Next Level
#9This 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.")
Re: Devcards – Taking Interactivity to the Next Level
#10This 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…
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.