Alternatives to Crello

As a #Frontend developer I'm used to using tools like #BootstrapCDN or some APIs/Library like #GoogleMaps to create or have styled elements with cool functionality. But this requires me remembering Bootstrap classes, or trying to get Google Maps to work in #Angular. 😢

And that's just framework agnostic solutions... If you look at framework specific libraries you end up dealing with the fact you are pigeon holed into using framework specific libraries!

Libraries like Polymer or Stencil for #WebComponents are definitely the way to go!

The tool we use for editing UI is React Storybook. It is the perfect place to make sure your work aligns with designs to the pixel across breakpoints. You get fast hot module reloading and a couple checkboxes to enable/disable browser features like Flexbox.

The only tricks I apply to Storybook are loading the stories with the mock data we’ve extracted from the API. If your mock data really covers all the various various possible states for your UI, you are good to go. Beyond that, if you have alternative states you want to account for, perhaps loading or error states, you can add them in manually.

This is the crux of the matter for Storybook. This file is entirely generated from Yeoman (discussed below), and it delivers the examples from the Alps Journey by default. getSectionsFromJourney() just filters the sections.

One other hack you’ll notice is that I added a pair of divs to bookend my component vertically, since Storybook renders with whitespace around the component. That is fine for buttons or UI with borders, but it’s hard to tell precisely where your component starts and ends, so I hacked them in there.

Since we are talking about how all these fabulous tools work so well together to help you be productive, can I just say what a delight it is to work on UI with Zeplin or Figma side by side with Storybook. Digging into UI in this abstract way takes all the chaos of this madcap world away one breakpoint at a time, and in that quiet realm, you are good down to the pixel every time.

To supply Storybook and our unit tests with realistic mock data, we want to extract the mock data directly from our Shared Development Environment. As with codegen, even a small change in a query fragment should also trigger many small changes in mock data. And here, similarly, the hard part is tackled entirely by Apollo CLI, and you can stitch it together with your own code in no time.

Coming back to Zeplin and Figma briefly, they're both built to allow engineers to extract content directly to facilitate product development.

Extracting the copy for an entire paragraph is as simple as selecting the content in Zeplin and clicking the “copy” icon in the Content section of the sidebar. In the case of Zeplin, images can be extracted by selecting and clicking the “download” icon in the Assets section of the sidebar.

We chose Figma because of the collaboration aspect of it. We are able to work as a team to create designs for web apps, mobile apps, and alike. After creating our designs in Figma we start exporting the assets and designs over to Webflow and Supernova.

How we ended up choosing Confluence as our internal web / wiki / documentation platform at Katana.

It happened because we chose Bitbucket over GitHub . We had Katana's first hackaton to assemble and test product engineering platform. It turned out that at that time you could have Bitbucket's private repositories and a team of five people for free - Done!

This decision led us to using Bitbucket pipelines for CI, Jira for Kanban, and finally, Confluence. We also use Microsoft Office 365 and started with using OneNote, but SharePoint is still a nightmare product to use to collaborate, so OneNote had to go.

Now, when thinking of the key value of Confluence to Katana then it is Product Requirements Management. We use Page Properties macros, integrations (with Slack , InVision, Sketch etc.) to manage Product Roadmap, flash out Epic and User Stories.

We ended up with using Confluence because it is the best fit for our current engineering ecosystem.

Our UX designers currently use Adobe XD and we are considering moving to UXPin with Merge. Our UI developers are transitioning to React and perhaps React Native, so I'm intrigued by UXPin/Merge abilities to leverage React components, both for improved design fidelity and easier integration with production components. If you use or have evaluated UXPin and/or Merge, I'm interested to know your observations on UXPin/Merge as a design tool compared to any alternative, as well as to what extent Merge delivers on its promise of seamless integration between designers and front-end developers.

I am working on a project for a client, I need to provide them with ideas and prototypes. They all have Adobe XD, but not InVision - I am the only one who will have that if purchased. I am trying to decide what would be the best tool to hand off the work to a developer who in terms will be working in PySide (Qt related) or Tkinter. Is there any benefits to me or the developer to work in Adobe XD or InVision. I am just trying to use the best tool to get the job done between the two.

Thank you in advance! Nadia

The tool we use for editing UI is React Storybook. It is the perfect place to make sure your work aligns with designs to the pixel across breakpoints. You get fast hot module reloading and a couple checkboxes to enable/disable browser features like Flexbox.

The only tricks I apply to Storybook are loading the stories with the mock data we’ve extracted from the API. If your mock data really covers all the various various possible states for your UI, you are good to go. Beyond that, if you have alternative states you want to account for, perhaps loading or error states, you can add them in manually.

This is the crux of the matter for Storybook. This file is entirely generated from Yeoman (discussed below), and it delivers the examples from the Alps Journey by default. getSectionsFromJourney() just filters the sections.

One other hack you’ll notice is that I added a pair of divs to bookend my component vertically, since Storybook renders with whitespace around the component. That is fine for buttons or UI with borders, but it’s hard to tell precisely where your component starts and ends, so I hacked them in there.

Since we are talking about how all these fabulous tools work so well together to help you be productive, can I just say what a delight it is to work on UI with Zeplin or Figma side by side with Storybook. Digging into UI in this abstract way takes all the chaos of this madcap world away one breakpoint at a time, and in that quiet realm, you are good down to the pixel every time.

To supply Storybook and our unit tests with realistic mock data, we want to extract the mock data directly from our Shared Development Environment. As with codegen, even a small change in a query fragment should also trigger many small changes in mock data. And here, similarly, the hard part is tackled entirely by Apollo CLI, and you can stitch it together with your own code in no time.

Coming back to Zeplin and Figma briefly, they're both built to allow engineers to extract content directly to facilitate product development.

Extracting the copy for an entire paragraph is as simple as selecting the content in Zeplin and clicking the “copy” icon in the Content section of the sidebar. In the case of Zeplin, images can be extracted by selecting and clicking the “download” icon in the Assets section of the sidebar.

Hey,

We are a diverse group of in-house UX/UI-designers who currently work in different software; XD/Sketch/InVision and so on. We need an efficient way to manage our workflow to build, share, and maintain a consistent yet dynamic design library and a smooth, less time-consuming developer hand-off. There are lots of things to consider, and where we're at the moment, it's "design in your preferred program, but joint library and handoffs should happen through Zeplin or Avocode." Which one of these two should we go for? Any other solutions?

Thanks!