aliusa
I was introduced to ARC when I purchased the EZ-Robot Module when it was still part of EZ-Robot. At that time there were no monthly subscription fees. At least not for the things I was doing. I have an R&D background designing and building large-scale enterprise software and user experience (UX) is a big part of software adoption and generally good design. I always thought ARC's UX could be improved drastically. But since it was freeware, I lived with it. But eventually, I stopped using it and gave up my robot project altogether because I found UX too cumbersome. Years later. my son recently got interested in robotics so rebooted my robot project with him. But that's when I remembered how much I disliked the user experience (and this time I wasn't alone with this opinion). But now since I'm getting charged for basic skills even when testing I thought it was appropriate to bring this up in the public forum. I honestly can't justify the cost of paying for software I know I wouldn't enjoy using and likely stop using it. It's definitely disheartening that I paid for hardware that is now tightly coupled to the ARC software and I am expected to pay more for something I don't even like
I'd like to contribute to the UX of the product and lend my experience to making the software better. But I'm curious what is the product roadmap and is the UX being addressed?
Thanks, Aliusa
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.
Not necessarily true. There might be other ways to increase the conversion rate from free to paid. I'll name just a few: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:
Don't do what Docker did!
Docker O_o lol...
That's all great feedback. Once the industry matures, we'll see hardware and product companies start to take over the subscription cost. Right now, the mentality of a hardware company is to produce a product, push it to the consumer, drop support and move on. As soon as a robot product is available for purchase, it has experienced its end-of-life tombstone. Our sales and marketing have scaled the partner discussions to have hardware companies recognize the value of long-term customer support (i.e., https://synthiam.com/Partner/add-a-robot-product-to-arc). It comes down to having the robot company bundle the ARC Pro subscription in their cost. They're already saving operational costs by not having to create their software, so you're right.
I wouldn't say there is much push-back, but more so, the re-education of their business model takes the most time. I felt the pain when I started EZ-Robot, which was a considerable endeavor. Not only did we have to create the hardware, but the software too - and the only reason there was hardware was because I needed something scalable for my software goals. I wouldn't have gotten into the hardware game if I didn't have to. However, I'm glad I did because I learned a lot, and that experience is irreplaceable.
I must value outside-in feedback and weigh it against my inside-out experiences. Albeit, it's a constant course re-alignment as the industry moves slow (or occasionally in the opposite direction). The industry today, for example, is fighting between expectation and reality. Robot and AI/ML companies are essentially deceiving customers and investors about the limitations of their capabilities. I'm not referring to the limitations of the technology; it's the knowledge limitations about the technology that is the issue. Meaning we know the possibilities, but we all can't agree on working together to achieve them - so the results are underwhelming. And that's due to lack of standards, mostly from ego. Everyone wants to re-invent how they implement a robot because their way might be the best. Contrary to belief, a standard isn't created due to popularity but industry dependency.
Once other industries rely on how robots are designed/built/programmed, it gets harder to change the process... voila, a standard.
A good example is Microsoft Windows, a heavy beast that moved fast as a shark but steered like a whale. Windows gained popularity so quickly that there wasn't much time for foresight. Well, much can be said about x86 architecture as well! And I believe they go hand in hand...
The summary is there's always going to be room for improvement until there isn't
DJ,
Appreciate the honest discussion. I completely understand the challenges many of which I too have faced. In the software world when we talk about scalability we often refer to the software scaling technically not the people part of the software. I'm sure there have been plenty of times you wanted to clone yourself One of my first challenges when founding a start-up was figuring when to bootstrap and when to seek investors--knowing that I'll be giving up a portion of the control. But to truly scale up and realize my vision I needed money, lots of money! After a year wearing the hats of Founder, CEO, CMO, CPO, CRO, and CTO it became very apparent I can't do everything. That's a tough pill to swallow, especially if you're a perfectionist! Cause anyone you hire won't do it the way your way and you have to learn to give up control in order to focus on other things.
The reason why I chose EZ-Robot years ago was because of the active community and friendliness of those in the community. I didn't find the usual RTFM comments you often hear in the techie forum when newbies ask basic questions. I hear plenty of newbie questions, thanks for your patience! Most of my time was spent on building the hardware so I didn't spend too much time in ARC. Since the hardware is now complete, I am actually programming it now that's where the UX rant came from -- honestly, you did an amazing job in building a great UX around the hardware, I was surprised by the software. Since watching my kids grow up and join STEM clubs I do think the functionality of EZ-Robot and ARC is far superior. Again it's the functionality but mostly the UX that I feel can be improved for further adoption.
I'm all about API first development. Cause this allows you to outsource or let people develop their own UIs on top of your tech, paying for a license for the use of your APIs. If I recall years back I thought there was an SDK. I would love to jump into code and program my bot in code!
I just want to reiterate, I am by no means calling your baby ugly! LOL (I know how that feels!). Just providing genuine feedback to help improve the adoption. Plus I am being selfish too because I spent all these years hacking my omnibot using your tech, last thing I want is for you to go under!
-A
You sure can program with code - there’s an option in ARC to create a robot skill. What’s nice about that is your code can use other robot skills or not. It’s really up to you on how to use it. It's in a few places, including the top and Add Control menus. The robot skill gives you access to the ARC SDK, which you remember. It's all bundled together now.
I’m not saying RTFM. But the website has a ton of information beyond the forum. It’s a neat evolution to watch. This is because our forum used to be intense with questions. We kept converting the questions into support documents and adding them to the website. In response to that, our software usage is super high, and our community questions are super low. We found most people don’t want to ask because they have enough social in their life, I guess. Or they’re just not interested in having an internet presence - who knows. But it’s neat how much information the website has for those who click on tabs other than community, lol.
here you go: https://synthiam.com/Support/Create-Robot-Skill/Overview
We focus on robot skills to allow third parties to publish their tech. When a third party makes a technology product and releases an API, they’re only halfway to getting robot builders engaged.
The robot skills allow robot builders to use the tech without learning the API and how to merge them.
For you, if a robot skill is still too high level, there’s also the communication protocol. So you can talk directly to ezb hardware with whatever code you want. It’s the same across all our supported hardware.
Since you’re coming from ezrobot days and haven’t explored the website yet - there’s a ton of supported ezb hardware. Ardunio esp32 robotis etc etc
Even our firmware is open source to add features to any ezb, and ARC will support it. You can see that with some robot skills that require specific firmware.
When connecting to an ezb, you might have noticed the list of Capabilities. Those are how ARC knows what the ezb is capable of. When viewing firmware, you’ll see capabilities listed.
The website is a rabbit hole for techies. Try it but don’t forget to come up for air!
Oh, I want to continue our conversation about third parties and their UIs in ARC. So one of the challenges that I mentioned in my response about there being a lack of standard in robotics is what you're recognizing. Every company that makes a robot skill with us has a different API implementation. Their product's API or SDK is drastically different than everyone else. So the GUIs they create are always a bit off. We provide standards to build from, but their technology might not fit the form factor.
What you're experiencing is the issue I outlined - no standard, no responsibility, no problem - is what technology companies think. They shoot from the hip and push their tech rather than considering the integration interface.
Wow, I can't even begin to explain some of the crazy integrations we've had to do. Everything from streaming JSON hacked over HTTP in one tech, and the next (from the same company) is an XML web service accepting HTTP posts with authentication in headers.
To be agnostic means dealing with everyone's lack of agnostic intent!! (don't worry, Synthiam will figure it out) Eye roll lol