[HN Gopher] Show HN: Judo - Build Native App Experiences with No...
___________________________________________________________________
Show HN: Judo - Build Native App Experiences with No Code
Author : krzyzanowskim
Score : 96 points
Date : 2021-08-13 10:31 UTC (12 hours ago)
(HTM) web link (www.judo.app)
(TXT) w3m dump (www.judo.app)
| mdomans wrote:
| Oh boy, the IJF is going to have an epic hissy fit
| enahs-sf wrote:
| If you thought they were overreacted about leg grabs, wait
| until they see this.
| leetrout wrote:
| https://www.ijf.org/
| erikig wrote:
| Is there a showcase of live apps that are built on Judo?
| holoduke wrote:
| Playing the devil's advocate here. But what problem is this
| product trying to solve. Completely unclear. Is it by reducing
| development needs?
| danpalmer wrote:
| I've only read the marketing page, but I'm thinking of it as
| less of a no-code app builder, and more of a smarter-than-
| average CMS. If you can hand off a whole section of your app to
| a content or marketing team to handle that's quite a boost to
| velocity.
| ruckstar wrote:
| Ya, we've been using the term "server-driven UI" to explain
| what we do.
| darylteo wrote:
| So... this is a sdk + platform that basically downloads a
| "description" of an app onto the device, then builds a UI based
| on that description?
|
| Is this actually positioning itself to be a realistic replacement
| for production ready native apps? Or is this just meant to be a
| rapid prototyping / 1 use throwaway apps?
|
| From the use case it seems one could use Judo for specific parts
| of an app, for example, a user onboarding flow, together with A-B
| testing, while allowing the rest of the app a native build?
| ruckstar wrote:
| Judo is meant to integrate into your existing iOS and Android
| app. It's not an "app builder" platform. Instead, Judo
| facilitates server-driven UI for parts of your app where it
| makes sense. Typically areas that are displaying lots of data
| driven content and/or benefit from rapid iteration. It's also a
| great fit for ephemeral marketing content that doesn't make
| sense to be built by hand and go through a full release cycle.
| jnwatson wrote:
| This information should be more readily apparent from your
| landing page.
| ruckstar wrote:
| Agreed. We have work to do!
| mithusingh32 wrote:
| Is the title is misleading? It sounds like it's a tool to
| build server-driven components for your native app?
| ruckstar wrote:
| It's both a no-code tool for building native mobile
| interfaces AND a platform for hosting/serving them remotely
| (i.e. server-driven UI). It doesn't make sense to use this
| for your entire app but it's an invaluable tool for certain
| use cases.
|
| We're still playing with our marketing language. Very
| interested in feedback on how you'd position this.
| danpalmer wrote:
| I was quite confused as well. I assumed from the
| beginning that this was a tool for building a whole app,
| and I was confused about why there was no App Store/Play
| Store process involved, and how any backend logic would
| work.
|
| What I understand now, and where I see the value, is in
| this being a low-logic CMS - i.e. you can do a lot more
| than a flat article, but you likely wouldn't build a full
| app with it.
|
| I can imagine us (as an iOS team) adding this as our Blog
| section in the app, and handing over responsibility for
| all the design, navigation, interaction, and articles, in
| it to our content team. They might even make our article
| much more interactive with this (quiz idea is great!).
| Currently they use a regular CMS for posts and we handle
| all the information hierarchy which isn't ideal.
| ruckstar wrote:
| Great feedback, this is really helping us understand how
| to improve our messaging. The blog section in your app is
| a great use case.
| lxe wrote:
| I'm seeing a lot of HN lauch posts with "book a demo" link
| instead of a demo video or demo app or pricing page. Why is this
| becoming a trend?
| dang wrote:
| I don't know but if any YC startups get away with that on HN,
| please let me know at hn@ycombinator.com because I'm telling
| them all not to do it.
| rvnx wrote:
| I registered on the website, got pretty confused by the fact
| nothing tells you how to create an experience. Nowhere there is a
| link to the editor app. The link is on the homepage but the
| homepage redirects you to the control panel if you are logged-in
| so you have to open an incognito session.
|
| Once you have the incognito session, you can find a download
| link, but it opens the App Store, which requires an account,
| which requires a bank card to download.
|
| Is there a .dmg somewhere ? (I cannot use the software due to
| that, Apple keeps rejecting my bank card, but it's a bit sad
| because I'd like to try).
|
| Also, where is the pricing ?
|
| What if your servers are down ?
| ibdf wrote:
| Yeah... anytime I don't see a pricing page but see a "book
| demo" link I immediately stop navigating and move on.
| ruckstar wrote:
| There will be self-serve pricing coming very soon. In the
| meantime the product is free to use. Feel free to reach out
| via our contact form if you want to discuss pricing sooner.
|
| https://try.judo.app/contact-us/
| duped wrote:
| That's what makes it a great filter.
| ibdf wrote:
| That's a very good point.
| ruckstar wrote:
| Good feedback. We're still ironing out the onboarding UX. In
| the meantime, this getting started page should help:
|
| https://try.judo.app/getting-started/
| steve_taylor wrote:
| You don't need a payment method to download free apps from the
| App Store.
| rvnx wrote:
| It depends on the country I guess, skipping credit card
| details page forces me back to the account registration step.
| RussianCow wrote:
| When I created my Apple ID ~6 years ago, it forced me to
| enter my CC info before installing any new apps (even free
| ones). Is this not the case anymore?
| fnord77 wrote:
| not sure about now, but there was some really roundabout
| way to do this.
| krzyzanowskim wrote:
| check Learning section: https://vimeo.com/judoapp it's full of
| short video tutorials you can start with. The app is available
| in AppStore for free
| danpalmer wrote:
| I like this a lot. I'm currently thinking a lot about how to
| expose more control of our article content to our content team.
| They want to be able to build much more complex layouts, use more
| imagery, embed videos, control the information hierarchy, and
| even do basic interaction like buttons to go to show/hide
| different content.
|
| We're all SwiftUI, so while creating each bit of this isn't a lot
| of work itself, we need to add it to our API, backend, CMS,
| editor, database, etc. The more control we can give them over all
| this the better.
|
| That said, there are things where we (as an engineering team)
| still need some control. Device support, accessibility - I can
| see these are fully supported and can be previewed, that's great!
| A few things that look missing that it would be good to see:
|
| - Design system/styles/etc - we have a set of styles, colours,
| typefaces, padding sizes, etc that we want to use and/or strongly
| encourage.
|
| - Custom data. We'd like to be able to pass in details from the
| system, like who's logged in, name and other user properties that
| matter in our product.
|
| - Custom components. We have things like a product card component
| that it would be great to be able to re-use here. How that would
| get its data though... not sure.
|
| - Custom actions. I can see something about this in the app but
| not sure how it works. We would want to be able to link to places
| in the app, ideally with URLs, and have responsibility of
| presenting that UI handed back to the non-Judo part of the app.
|
| I may be assuming a lot about the product here, maybe this isn't
| the direction you're thinking, but I'm generally excited by this
| and keen to see how it develops over time.
| ruckstar wrote:
| You're thinking bang-on about the product and where we're
| going.
|
| Regarding design systems, we have a feature coming that we're
| either calling Components or Symbols (Sketch's term), we
| haven't decide which yet. The idea is to package up a
| configured set of layers into a saved "thing" that can be
| reused across your experiences. For example a standard button
| made up of a rectangle, image and text. Designers/builders can
| then use this button anywhere in their experience and override
| the value of the text while retaining the style (size, color,
| font, drop shadow etc.).
|
| Custom data is supported today! You can pass information you
| know about the user locally to the SDK and use it to
| personalize your experiences. In the Mac app you can also
| supply sample user values in the Document Inspector to preview
| how your personalized experiences will look when viewed within
| your app by a real user. After adding sample values in the
| Document Inspector you can use {{user.}} to insert those values
| into your text layers.
|
| For custom components, you could either build them as Judo
| components/symbols when they come out. We have also floated the
| idea of inserting placeholders in the Mac app which are
| replaced with your own custom components when rendered in your
| app. Although we haven't fully thought through how this will
| work yet.
|
| Custom actions are supported today through URLs with custom
| schemes (aka deep links). You can attach an action to any layer
| in Judo and supply a custom URL you want it to open when the
| user taps it. We are expanding on what you can do with buttons
| in an upcoming release so more to come there as well.
| ruckstar wrote:
| I should also add, for your question about custom components,
| if you build them in Judo, they can be connected to your own
| APIs via the DataSource, Collection and Conditional layers.
| It's not super intuitive atm but we have a video course on
| how it works dropping next week. In the meantime, if you want
| to try out data sources and get stuck, let me know and I can
| walk you through it.
| danpalmer wrote:
| This all sounds great, thanks for the additional info!
|
| > For custom components, you could either build them as Judo
| components/symbols when they come out. We have also floated
| the idea of inserting placeholders in the Mac app which are
| replaced with your own custom components when rendered in
| your app. Although we haven't fully thought through how this
| will work yet.
|
| While I'm sure just building these as Judo components would
| be quicker, I must give a strong +1 to the placeholder
| concept. Just thinking about our product card component,
| there are 3 different interactions, 10+ different visual
| parts, it's a core concept repeated throughout the app, there
| are lots of analytics things tied to it, and it has been
| optimised a fair bit. I don't think we can reasonably expect
| to rebuild a version in Judo that meets our needs, and I
| think that would be misusing Judo for things it's not really
| designed to do.
| a-priori wrote:
| As someone who practices Judo (the martial art) this made me very
| confused.
| krzyzanowskim wrote:
| FTW Maximum Efficiency with Minimum Effort
| a-priori wrote:
| I'm totally on board with applying the principles of judo,
| such as Seiryoku-Zenyo (the efficiency principle you
| mentioned), more widely than throwing people into a mat while
| wearing a particularly sturdy bathrobe.
|
| But I'm not going to lie, seeing it used like this makes me
| cringe.
| rchaud wrote:
| Is there a reason the desktop app requires Mac OS 11?
|
| I'm interested in this area as marketing teams do need to create
| ephemeral apps every now and then. One of my favourites is the
| Nike Lookbook App of 2015; by far one of the best and most
| visually creative things I've seen. Unfortunately it was removed
| from the app store.
|
| https://news.nike.com/news/tech-book
| ruckstar wrote:
| You could build the entire Nike Lookbook as a Judo experience
| and deliver it through the primary Nike app. This is one of our
| most common use-cases.
|
| Marketing teams often want to build engaging experiences like
| the Nike Lookbook and use them to engage with their core app
| audience. But an experience like this is ephemeral--it's only
| relevant for a short period of time. It wouldn't make sense for
| the core engineering team to build it by hand. By the time it
| made its way through the app release cycle and (hopefully)
| users updated to the new version of the app, the experience
| would no longer be relevant. And you'd need another app update
| just to remove the code they wrote for the experience.
|
| This is a great use case for server-driven UI. Judo enables
| teams to design, build and deliver experiences like these
| through their native apps without writing code and without
| having to release an app update.
| douk wrote:
| The macOS version requirements might have something to do with
| the fact that it was written in SwiftUI.
| ruckstar wrote:
| Ya you got it. SwiftUI wasn't viable before Big Sur.
| peterthehacker wrote:
| Can Judo build native desktop apps as well or just mobile apps?
| ruckstar wrote:
| Right now we support iOS and Android. But we have Mac support
| on the roadmap.
| jonbaer wrote:
| Just curious, would it be Catalyst based?
| https://developer.apple.com/mac-catalyst/
| ruckstar wrote:
| We are planning full Mac support for Mac apps that are
| built with SwiftUI. But if your Mac app is built with
| Catalyst it may very well work today...
| binkHN wrote:
| "Judo is a Mac Application," so Mac only
| krzyzanowskim wrote:
| editor is Mac only. SDK to "run" created experiences is for iOS
| and Android.
| steve_taylor wrote:
| Where's the documentation? I can't figure out how to use a data
| source. I've been able to add a collection to it and set the path
| to the array in the API response, but how to I render data from
| the collection?
|
| Edit: Figured it out. It uses double brace syntax, e.g.
| {{data.email}}.
| ruckstar wrote:
| Glad you figure that out :) We have a video course dropping
| next week dedicated to DataSources and Collections. In the
| meantime, you can take a look at this example experience which
| makes heavy use of DataSources and Collections. It is connected
| to a Contentful API.
|
| https://www.dropbox.com/s/owi4g0kgl7o4pej/FitnesExperience-D...
| IggleSniggle wrote:
| Just FYI.
|
| Not sure about others, but I almost never watch video content
| to learn how to do something with a computer. I don't like
| needing to have audio turned on, they are often either too
| slow or too fast, and they don't allow me to move at my own
| pace / jump around as easily.
|
| Video is a _great_ medium to convince me to try something or
| show me _why_ I should do something a particular way, but not
| the medium I want to use to learn how to use a thing
| generally. Really prefer text and occasionally text+picture.
| ruckstar wrote:
| Good feedback, thanks for sharing. I have passed these
| comments on to Kevin the product specialist in the videos.
|
| We have a new Learning Center section of the website
| launching soon that will organize all the content into
| lessons and courses. At that point we can include text and
| images as well. The Vimeo page is a temporary workaround
| until the Learning Center launches.
| secondaryacct wrote:
| When will we be able to build native experience without apps next
| !!?
| code_duck wrote:
| I'm looking for a way to run apps with no hardware.
| rvnx wrote:
| It's called Imagination
| trutannus wrote:
| I believe that's what they mean when they say a program is
| 'cloud native'. Clouds are vapor, therefore this means the
| program is, by definition, vaporware.
| henning wrote:
| There's no code just like serverless apps have no server.
|
| There is still code. You just no longer control it. If it doesn't
| work the way it needs to, you are completely fucked.
| astlouis44 wrote:
| OK I have to know - what framework did you use to make your front
| end landing page? It's absolute beautiful.
|
| I'm guessing React?
| pluc wrote:
| WYSIWYG editor for native development
|
| what could possibly go wrong
| steve_taylor wrote:
| Not purely WYSIWYG because you can't arbitrarily place anything
| anywhere. It seems to be based on SwiftUI and carries over a
| lot of those concepts into the builder.
| ruckstar wrote:
| Exactly. We love SwiftUI's layout system. It has a learning
| curve but once you "get it" it feels so intuitive to build
| naturally responsive layouts.
|
| Since our SDK is rendering native SwiftUI we decided the best
| experience would be to surface the API of the underlying
| layout system in a visual way. Similar to how Webflow
| surfaces HTML/CSS.
|
| Of course this meant building a SwiftUI renderer for our
| Android SDK. We are considering a future release where the
| Mac app exposes both SwiftUI and Jetpack Compose to allow a
| full visual build experience that is 100% native to both
| platforms.
| mellosouls wrote:
| Where's the "Show"? It would be useful to have a straight link to
| an immediately useable instance.
| jonbaer wrote:
| File -> Share -> Airdrop is the closest thing I have found, I
| am sure a preview is in the works ...
| ruckstar wrote:
| Ya right now sharing to your iPhone with Airdrop is a good
| workflow. You can also send experiences via iMessage and it
| will open directly in iMessage because we implemented the
| QuickLook extension.
|
| Also, we are currently working on implementing the
| FileProvider extensions on macOS and iOS which will
| facilitate automagically syncing between your Mac and
| iPhones. This will make it really easy to share experiences
| with everyone on your team.
| dmix wrote:
| Is CX the new word for UX? Took me a minute to figure out what
| "We put the X in Mobile CX" meant.
|
| I've heard people not wanting to call customers "users" but
| haven't come across it yet. IMO it only makes sense as a
| distinction from the end-user. Otherwise user is already well
| embedded in our language (username, user interface, user manual,
| etc).
| danpalmer wrote:
| Not sure we're in line with the rest of the industry but we use
| "users" as a general term and "customers" to refer to those who
| have placed an order with us at any point. That distinction can
| be quite useful when discussing user/customer journeys.
___________________________________________________________________
(page generated 2021-08-13 23:01 UTC)