You must be the only one not liking the user experience of ARC. Just try ROS for a bad one and then let me know.

Interesting. You're obviously a skilled professional with deep personal view on what you like and prefer. Your tools are your software development skills and knowledge that make that happen. I understand that mindset as I've been a professional craftsmen who used my hands and tools all my life to build and repair things. I also have deep feeling and preferences over the tools I use and the methods that I use them.

I'm curious, What don't you like about the ARC UX and how would you change it?

@Dave

My most obvious complaint is the layout. Windows overlapping windows, no way to search for things you have to scroll down to find them. Too much is obscured in just the layout. A nice feature would be a toggle between "UI" representation and "code" representation. So if I use a skill I should be able to click a button that shows the code version that I can manipulate. This is particularly useful for coders and for rapid development because it reduces the number of clicks when looking for variables, configurations, etc.

Within ARC you have multiple User interfaces: code, blocky, and ad-hoc skills you can incorporate. But is not always interchangeable. WIth any UX design, you want to identify all the personas who will use your application. And then tweak the UX based on that persona. Right now it's a mashup of everything.

These UX issues typically happen when you have an engineer wearing all the hats I've been there and done that. lol

Sorry to hear you're having UX issues. Perhaps walking through the support getting started guide will help understand the layout? As for robot skills, they each have their unique configuration settings because they're entirely different programs. There isn't a "single code" that works across all robot skills. If you're coming into any software with a different mindset, it takes a while to re-adjust. Give it some time using it, and I believe you'll understand. Of course, feel free to provide detailed suggestions as they're far more useful than rants

This is an excellent place to start: https://synthiam.com/Support/ARC-Overview/interfrace-workspace

Is there a particular feature that you'd like additional clarification with?

Hi DJ,

I was just giving an example but I understand what you're saying. And that's the thing, good UX is intuitive, not requiring re-adjusting. Ultimately a good UX will help with the adoption of your software and grow your business. Since you have the basic building blocks in place it's a matter of hiring a UX designer to help identify the personas and patterns.

My latest frustration happened while developing face recognition after x tries I was over my limit. These limits don't allow you to properly develop/test your robot. And instead of wanting to pay for ARC I rather use something else. I'm sure that's not your aim. This is all part of the UX.

Thanks,  A

Hi Aliusa, I'll take it here as DJ volunteers his time for technical robot building questions when he isn't working.

The free version of ARC is for users to experience the potential of our hard work to understand how our platform can aid in programming your robot. We believe that people would not pay for our software if we increased the free limitations, and therefore our company would have financial challenges maintaining operations and ongoing development.

There are three editions of ARC available. A free version (Teams) to experience the potential. A paid pro version (Early Access) with unlocked features. And finally, another free version (Runtime) runs ARC existing projects in read-only mode.

We put thought toward staging the edition so users can begin with an entry-level (Free) edition to get an idea of what they will experience. Then, choose to pay for the software (Pro) to program a robot. Finally, once the robot is programmed and operational, they can stop paying and use their robot program forever on the robot.

With a small team developing ARC's platform, robot skills, website features, and customer support, the revenue from customers who value the software helps us continue operations.

If you have suggestions to make the product better - that's what I'm here for Amy

Oh, thanks, Amy - yeah, what she said. I'm always good at receiving feedback and suggestions. The most challenging part with the UX is the config menus for each robot skill. Each robot skill is an entirely different technology with unique options and settings. The companies we work with to create the skills have different features or integration methods.

A while ago, there was a discussion about having robot skills be standard size and letting them snap to a grid. Although, that's "sort of" what the "auto arrange" option does. From what I recall, the tests had some issues. I believe it had to do with various screen resolutions of different computers. So the grid system ended up with robot skills all over the place. The solution was to keep the Auto Arrange option.

I know there is a search option in the Add robot skill menu being implemented. I'm not sure where it is now, but there's work being done on it.

From a business standpoint, I work for a unicorn that makes millions providing support around free open-source build solutions.

Quote:

We believe that people would not pay for our software if we increased the free limitations

1. Mac Compatible version
2. You can remediate the above issue by porting a web-app version of the solution.
3. Actually going with option 3 you can utilize existing UX patterns built by the open-source community that has been tried and tested.
4. Focus on the marketplace and generate revenue from there rather than individual end-users. This will help build your community.
5. Providing more free skills to help with your adoption
6. Charge super users and enterprises
7. Include a user-based license model
8. Charge for support, professional services, skill-building
9. Add more hardware modules  .... I can keep going.

But limiting usage you are actually creating a barrier to entry. It isn't allowing end-users to see the art of the possible.

The reason why we are able to make millions from free software is that we have a large community that uses the product. It ends up being very sticky. And people are willing to pay for support and services. They build an affinity towards the platform. You have that with a select few but I think you can increase that exponentially if you follow some successful open-source models. Examples:

• Jenkins
• Kubernetes
• Hashicorp Vault
• etc.

Don't do what Docker did!