OutSystems, a low-code application platform vendor, publishes posts on rapid app development, visual programming, and enterprise software.
HN commenters are mixed: one finds visual tools fine for simple CRUD but painful for complex logic, another says it was hard to tell what OutSystems sold.
OutSystems is looking for Senior Product Designers!
You will take the lead in designing the user experience for some of our most ambitious product development initiatives, side by side with other talented designers, in strong collaboration with our R&D development teams.
You have experience with some programming languages and IDEs (and have ideas on how to make them better), which allows you to get down and dirty with engineers, when required. You will combine that know-how with a Usability mindset to get the best possible solution matching technology and people for an amazing experience.
R&D Product Design strives to build a product users fall in love with, applying some of the most recent practices in product research, ideation and design to create solid grounded experiences, which provide moments of delight.
Key Responsibilities
. Be an advocate for the product design practices in the R&D area, and voice our users’ needs to help build a better product.
. Collaborate with cross-functional teams, within an Agile approach, to drive the design process from ideation to product delivery and launch.
. Head user and product research, lead ideation processes, detail end-to-end mockup solutions/prototypes, and drive user testing sessions in iteration for proven great solution.
. Get into our developers’ shoes to effectively find issues and draw pragmatic solutions.
. Help in the development of the Product Design practice and in the training provided to other teams.
. Be…
At work, we had a short experimental phase with using a visual programming tool to create web applications[1]. For simple CRUD applications it was actually really nifty. But as soon as you get to more complex logic, it turned into a nightmare.
I think part of the reason is that a chart or a graph is great to give you an overview, to transport the gist of a message, to convey informal information. Programming on the other hand is all about hard, precise logic. Text is a much better medium to present this. And it's much easier to divide and conquer in text form, with meaningful function and variable names.
For example, how would you represent the following simple code snippet graphically?
if (!customer.hasOrderedSince(DateTime.Now.SubtractYear(1)) {
offerCoupon(10);
}
In the aforementioned platform, this would be one rhombus (representing the if statement). You'd have to click it to see what the condition actually is. If you have a complex flow, you'd have to click all nodes to see what's actually going on. In text form, it should ideally fit onto one page and is much easier to grasp and debug.
Someone brought up that GUIs and mouse input has been successful, and that's true. But there is big difference between using a computer, doing small atomic tasks with it, and programming one.
[1] http://www.outsystems.com
Is vendor lock in really that significant, though? If it is to an organization I see that more as a management failing than a technology failing.
An example of where I'm coming from: https://www.outsystems.com/blog/posts/vendor-lock-in/
I think past vendor lock in wasn't so much about the technologies involved, but the inability of organizations to transform. If you have the right approach to application development/deployment/management there isn't a way any vendor can lock you in for any significant amount of time. I see more people wasting resources developing to avoid lock in when the applications they are developing won't live long enough to ever worry about having to move off of the systems they are developed on.
I'm not saying we should never be concerned about vendor lock in, but I think the concerns need to be balanced against the costs (and complexity!) of engineering everything to be immune from "vendor lock in".
>Sure, but the option of third party app stores opens also option of sideloading. In the case of Apple, when Apple says no, you are without the app, period.
This is a non-issue that people have brought up countless times. First of all, are we in agreement that app stores and other legal entities have to obey local laws? So your point is moot. Side loading is possible on iOS. You don’t even need to own a Mac to develop for iOS. [1,2,3,4] There is also the open web to fall back on.
And you are incorrect about user tracking. Just a day ago Google was caught tracking users even when location services are turned off. [5] And please educate yourself about modern ad tracking [6]
[1] https://www.outsystems.com
[2] https://www.xamarin.com
[3] https://cordova.apache.org
[4] https://www.xojo.com
[5] https://qz.com/1131515/google-collects-android-users-locations-even-when-location-services-are-disabled/
[6] https://donttrack.us/
If that was the case, Google wouldn't be pushing Houdini, and everyone else pushing WebGL and WebGPU.
By the way, already mastered all CSS tricks to force hardware rendering?
Motif might be irrelevant, yet its ideas live on across all modern toolkits for native programming and the Web had to wait for the WPF team to bother submitting WPF grids to W3C as base concept.
Delphi and VB are doing pretty well.
https://www.embarcadero.com/products/delphi?aldSet=en-GB
https://visualstudio.microsoft.com/vs/features/net-development/
And their ideas influence one of the best Web RAD tools, that only we in enterprise care to use.
https://www.outsystems.com
[Disclaimer: OutSystems employee here] I'm sad you find the experience bad. Eclipse or VSStudio integrations is part of our focus on being able to extend the platform to the max, but the need for it is only required when you are at a very specific use case.
I'd advice you to take another look. For example take a look at this tutorial (https://www.outsystems.com/training/courses/124/reactive-ui-development-101/) and see everything you can build with OutSystems.... without Eclipse :)