Indeed, we have a weird intermittent failure on component loading that we haven't figured out yet. A few reloads tends to work, as a temporary workaround.
I could publish a very simple app, but I'm not sure where I can "install" it? Mobile Firefox maybe?
Anyway, pretty neat visuals but a bit of lack of documentation right now. But I assume it's not yet ready to use as they did not communicate on this right now.
"I can't figure out if it's a game or some GUI for basic apps or what."
That seems rather disingenuous in light of:
"I lost interest fairly quickly, and half of the components seemed broken."
Seems that you figured out what it was after all, if you knew those were components.
Nothing wrong with negative feedback if it's constructive, but this seems to be a response in the category of "I couldn't be bothered to actually think before I wrote".
Looks like a bug. I tried it out and it had a component called 'randomcat' on that part. It was just as straightforward as the button. But I just tried it again to take a screenshot to show you, and it didn't come up.
It's like that Simon Says game. You have to complete all the previous steps plus the current one in order to progress to the randomcatfireworksratingsplosionbutton final stage, at which point you are deemed worthy of conquering the app store. If only I could get some kind of Mozilla Appmaker certification badge...
LOL, yes, this is exactly what I did. It felt like I wasn't supposed to be seeing what I was seeing, like the software was some kind of funny inside joke at Mozilla or something.
All I could think after that was - Is Random Cat funny? Is this something I should know as a developer? Am I out of some loop?
At any rate, it was so odd I just decided not to do anything else, and left. I think they goofed here, but once it's fixed, I'm sure people will go back.
That being said, it does go down as possibly the biggest tutorial fail I've seen to date - and I'm a little shocked given the source.
There is a GREAT lesson to be learned from this - and that's probably that leaving strange humor out of sign-up processes and tutorials is a good idea. I've seen other sign-ups that try to be "funny" and it just throws me off.
Agreed. Reminds me of a joke at the end of Django tutorial[1]:
Coming soon
The tutorial ends here for the time being. Future installments of the tutorial will cover:
* Advanced form processing
* Using the RSS framework
* Using the cache framework
* Using the comments framework
* Advanced admin features: Permissions
* Advanced admin features: Custom JavaScript
I get it now. It now seems kinda funny. But when I was new to Django, I thought it was serious. I used to visit the page once in a while to check if new tutorials have been added yet. Fortunately, 1.4 was the last version which included this "joke".
I think I said this in another comment, but the gamification levels were really just to test our gamification APIs, the levels are not at all right, or useful. We'll remove that ASAP.
That's fast, nice! I wonder if you could "anonymize" the phone, which looks too much like an Apple device for my taste. I think Mozilla has always shown the right direction for net neutrality, and trademark neturality is also important in my mind.
True, but most of all we value working in the open so that we can both do user testing and find people who might want to contribute. In my book our mistake was not to prioritze issues 306 and 386 until we showed up on HN. Oh well!
Can I suggest not using alpha/beta - they are labels used to indicate the state of a proprietary project - how "polished" it is - whereas you are continuously exploring. if you must I suggest using a target audience - contributors, early adopters. etc etc
Since nobody can seem to figure it out -- As near as I can tell, this is a not-quite-fully working app-maker demo, that 'publishes' to static HTML and Javascript files hosted on Amazon S3.
The gamified GUI is a little bit confusing, and you end up with a resulting 'app' (that sometimes takes a few reloads to work, oddly) with an Install button that doesn't seem to do anything yet -- but which I suspect will be a link to save 'as an app' icon to your mobile phone's homescreens.
It's not fully baked, at the moment, and it appears that some of the widgets aren't loading, but it's definitely a neat proof of concept, that was either leaked early, or is for some reason swamped under load, or something.
my friend's mother-in-law makes $76/hr on the internet. She has been fired for 9 months but last month her payment was $14190 just working on the internet for a few hours. this big57.com
Sadly, as it seems to be the comment I leave most these days, it doesn't work on mobile browsers. At least mobile Safari.
I understand that there are some interfaces that aren't meant for mobile. There are some that aren't meant for desktop. But at a minimum, you have to make some small effort to give a message to those visiting from unsupported platforms. It shows that you care.
If it doesn't seem like you care about the experience I'm having with your product then I have no motivation to go back and try it again.
We're actually very interested in mobile browsers, so much so that in fact we've got plans (with no code to back them up yet) to let people author apps wholly on a phone.
Please! Resubmit a link when the mobile version is ready. Again, I don't care if it works or not. All I'm saying is that since we're all browsers at some level we support basic html. Just put a notice it ain't ready for mobile and that's good enough.
The seed for the entire idea was actually people in mobile-first environments—developing countries, etc—and helping empower them to make software for themselves and their communities.
We started with desktop authoring, and it's been a useful step on the way to a mobile-first UI.
Will be really cool when people can generate apps on their phones, publish and share them, using only touch.
nice Signals/Slot mechanism, similar to Qt. The color of the line needs to be matched to connect a signal to a slot. Customization of signals/slots seems to be not supported atm.
That's right—and the priority is to let people with little or no progamming experience make their own mobile apps. Think Hypercard.
We're shipping a bunch of starter components to begin. In the future, we're looking at opening to contributors to submit their own components. We may have some advanced component editing at some point in the future, but the priority is a delightful experience for people who don't know how to code.
The tutorial crashed for me, but after a refresh I made an app that took a photo and stored it in a gallery. There seems to be a lack of useful widgets, and few ways to customise them. It certainly has potential though, and I'll be showing some of my students on Monday
From someone peripherally involved in the project:
This is an open source project, community-built from the beginning. It's pre-alpha. Pre-pre alpha, even. There has been no public launch or fanfare. That's why you'll see no blog posts or explanatory text yet, why many of the components don't work, and why the tutorials aren't built.
But it's cool to see that it's already found its way to HN.
Whoa. Definitely wasn't ready for HN-style exposure.
As bmoskowitz pointed out we have some rough words about the project. For this group, I'd in particular point out the roadmap and CONTRIBUTORS.md documents on the github repo:
At the highest level, we're exploring whether it's possible to make a tool that lets non-devs (_not_ you folks!) who currently see their phones as a pure engine of consumption, as a place where they can create something fun or useful.
It's very, very early software, and it's public mostly because a) we kinda don't know how to do anything else, and b) we're going to use early and frequent user feedback to correct the aim on the product.
If people are interested, we're more than happy to entertain questions either here or on github, irc, the mailing list, etc.
Oh, and yeah, many of the components are broken, brittle, etc. This is still just a prototype.
That said, we're getting positive reactions from people close to our target audience, such as high school teachers, people teaching others how to make their first app, etc.
I'm sure we have loads of x-browser compatibility bugs, as well as known issues with respect to accessibility, absent localization, no great mechanism for contributing new components, and many more.
Oh, and the gamification bits in particular were really just testing the gamification APIs -- the levels we have in place are deeply unuseful =).
"That said, we're getting positive reactions from people close to our target audience, such as high school teachers, people teaching others how to make their first app, etc."
I bet. But this is part of the problem with many of Mozilla's products targeting the education space (Open Badges, I'm looking at you). Teachers, administrators, bureaucrats think they're the cat's meow. But (of course) they want nothing to do with the implementation details. But they do expect them to be usable.
"At the highest level, we're exploring whether it's possible to make a tool that lets non-devs (_not_ you folks!) who currently see their phones as a pure engine of consumption, as a place where they can create something fun or useful."
That's a fantastic idea. So are open badges. But "us folks" are the ones that (whether we work in edu IT, at an edtech company, or are fellow travellers) are expected to make these half-baked great ideas work, reliably, in the real world, for educators and students.
I'm not trying to rant. Mozilla has great ideas for education.
But the poor (maybe I should be more generous and say incomplete) implementation of so many of these great ideas (Persona, Open Badges, and now Appmaker) is maddening when they're presented in a way that "not us folks" expect them to be available for production implementation.
Yeah, we need to do a better job of distinguishing "really early" from "ready for use". Expect a change in the landing page within a few hours (the team is currently scattered over three countries).
I'm your target market. Apart from my tech company, where I'm definitely not the technical founder, I also own a consulting company and construction firm. I've been patching together solutions with excel, trello, google calendar, etc, and this is exactly what i need.
Get it working, I always need tools customized to a particular task that a simple app would solve.
Hey HN, if you're curious about this, I suggest you watch this video (http://youtu.be/RaRIdLgZTPI) which shows a quick demo, and/or:
- opt out of the levels thing on first load, it's not ready.
- instead, jump straight in the designer and run through these few steps:
- drag & drop a button, click on it, notice it sends out messages on the blue channel
- D&D a counter, notice that it listens to a blue channel, and that the button clicks cause it to increment (that's how we "program" these components
- D&D another button, make it emit on a different color, and configure the counter to "count down" on that color. That way one button increments, the other decrements
- D&D the fireworks component, configure its "shoot this many rockets" to a third color (and clear "shoot rocket); make the counter emit on that color. Enjoy the fireworks show.
- Other components that work well for understanding things are:
- ratings widget
- input widget connected to a map widget will center the map on a place name (although HN will likely exceed the limits on our usage of the OSM server; need to setup another one =()
- flickr widget can do both topic and location searches
Let us know if you have ideas for components we should build (or submit a PR!).
The publish button will create "hosted apps" which can be installed on FirefoxOS, Firefox for Android, and incidentally recent builds of Firefox desktop, although the focus for Appmaker is very much mobile apps).
Sure, it's a bit rough around the edges, but it is a brilliant thing for non-devs to play around with. With a little tinkering sround, I managed to create a simple chatroom app: http://truthful-week-478.appalot.me/install.html
Here're my first impressions:
1. The color flow as a broadcast-reception link is an interesting idea but not immediately intuitive. Once I figure out what it was for, I managed to blaze through it fairly quickly.
2. Broadcast trigger actions need to be clearer. For instance, I know there a trigger for the randomcat but the fact that clicking the random cat is the trigger isn't all that intuitive.
3. Make chaining triggers a thing? I know it's not as easy as it seems but some combinations do lend themselves to chained triggers. For instance, I wanted to emit the random cat to the chat room with each text (as a test) but there was no way to chain triggers.
4. Publishing the app seems to lose the custom name assigned to form buttons. The app I posted above should say "Clear Chat" where it says submit.
5. Allow me to save my apps under a custom name? And publish the changes to the same app after Edit? Not sure about the latter - haven't tried it yet.
Overall, it is a brilliant achievement for something that is pre-alpha or pre-pre-alpha! I'd like to see where this leads!
I am now heading back to construct a simple clicker game. Wish me luck! :D
EDIT: Both Chrome & Firefox seem to throw errors about a few js files (primarily ceci.js & designer.js) in the console while loading the page for the first time. CTRL+F5 solves it. JS caching issue, I'm guessing? :)
This looks promising. I would love to see a basic HTTP component which can recieve broadcasts and in its simplest form perform HTTP GET to a specified URL. Also with the possibility to broadcast the response from this HTTP GET request to another component.
I am playing around with a Raspberry PI / Arduino solution and the PI has a webserver which relays commands to the Arduino. Now, it would be very neat to have a mobile app to trigger these commands. For example, pushing a button to turn a light on or off. As I do have minimal time creating GUIs, this tool, with the flexibility of a HTTP module, would be perfect to use for prototyping such solutions.
This could be used to trigger commands as described above, but also possibly for embedding content from other sites etc.
Probably not where you wanna go with this tool, but it would be neat for situations where you want a quick GUI to control stuff.
As someone that makes tools like this for a living (Codiqa and Jetstrap), and I have to say it's quite well done. Nice work, and I'm sure the bugs will get ironed out.
98 comments
[ 27.9 ms ] story [ 890 ms ] threadEdit: Working in Chrome now.
P.S. I was able to get random cats by using a button and a flickr though, it didn't work either.
I lost interest fairly quickly, and half of the components seemed broken.
https://github.com/mozilla/appmaker
and check out where we're intending to go:
https://github.com/mozilla/appmaker-words/wiki
That seems rather disingenuous in light of:
"I lost interest fairly quickly, and half of the components seemed broken."
Seems that you figured out what it was after all, if you knew those were components.
Nothing wrong with negative feedback if it's constructive, but this seems to be a response in the category of "I couldn't be bothered to actually think before I wrote".
clicks link on Hacker News
"Hmm, not sure what this is about. I'll just hit the 'Start' button"
Hits start button. 'Add a button' dialog pops up
"That seems pretty straight forward, I'll just add drag that thing labelled 'Button' from the left window pane, on to what looks like a smartphone"
Drags button over. Gets 'Congratulations' box
"Wow, this is really intuitive so far. With a little effort, something like this would be a real game changer in the mobile space!"
New dialog pops up: 'Add a randomcat component to your app
Looks around for anything labelled 'randomcat'
"Huh, thats strange. I wondered if it's labelled something else and I'm just missing it"
Looks for 'random', 'cat', 'Cat.random()', and any other possible combination
"Wtf mate?"
Gives up and leaves
All I could think after that was - Is Random Cat funny? Is this something I should know as a developer? Am I out of some loop?
At any rate, it was so odd I just decided not to do anything else, and left. I think they goofed here, but once it's fixed, I'm sure people will go back.
That being said, it does go down as possibly the biggest tutorial fail I've seen to date - and I'm a little shocked given the source.
There is a GREAT lesson to be learned from this - and that's probably that leaving strange humor out of sign-up processes and tutorials is a good idea. I've seen other sign-ups that try to be "funny" and it just throws me off.
[1] https://docs.djangoproject.com/en/1.4/intro/tutorial04/#comi...
That'd seal the deal for me.
The gamified GUI is a little bit confusing, and you end up with a resulting 'app' (that sometimes takes a few reloads to work, oddly) with an Install button that doesn't seem to do anything yet -- but which I suspect will be a link to save 'as an app' icon to your mobile phone's homescreens.
It's not fully baked, at the moment, and it appears that some of the widgets aren't loading, but it's definitely a neat proof of concept, that was either leaked early, or is for some reason swamped under load, or something.
I understand that there are some interfaces that aren't meant for mobile. There are some that aren't meant for desktop. But at a minimum, you have to make some small effort to give a message to those visiting from unsupported platforms. It shows that you care.
If it doesn't seem like you care about the experience I'm having with your product then I have no motivation to go back and try it again.
Filed as https://github.com/mozilla/appmaker/issues/387, thanks.
We're actually very interested in mobile browsers, so much so that in fact we've got plans (with no code to back them up yet) to let people author apps wholly on a phone.
We started with desktop authoring, and it's been a useful step on the way to a mobile-first UI.
Will be really cool when people can generate apps on their phones, publish and share them, using only touch.
We're shipping a bunch of starter components to begin. In the future, we're looking at opening to contributors to submit their own components. We may have some advanced component editing at some point in the future, but the priority is a delightful experience for people who don't know how to code.
Google Chrome 30.0.1599.66 (Official Build 225456) OS Linux Blink 537.36 (@158213) JavaScript V8 3.20.17.13
This is an open source project, community-built from the beginning. It's pre-alpha. Pre-pre alpha, even. There has been no public launch or fanfare. That's why you'll see no blog posts or explanatory text yet, why many of the components don't work, and why the tutorials aren't built.
But it's cool to see that it's already found its way to HN.
It's meant to be like Hypercard for mobile apps.
If you want to learn more, check out the repo:
https://github.com/mozilla/appmaker
or the vision stub / wiki:
https://github.com/mozilla/appmaker-words/wiki
As bmoskowitz pointed out we have some rough words about the project. For this group, I'd in particular point out the roadmap and CONTRIBUTORS.md documents on the github repo:
I wrote some earlier words at https://github.com/mozilla/appmaker-words/wiki, but that's quite possibly out of date.At the highest level, we're exploring whether it's possible to make a tool that lets non-devs (_not_ you folks!) who currently see their phones as a pure engine of consumption, as a place where they can create something fun or useful.
It's very, very early software, and it's public mostly because a) we kinda don't know how to do anything else, and b) we're going to use early and frequent user feedback to correct the aim on the product.
If people are interested, we're more than happy to entertain questions either here or on github, irc, the mailing list, etc.
Oh, and yeah, many of the components are broken, brittle, etc. This is still just a prototype.
That said, we're getting positive reactions from people close to our target audience, such as high school teachers, people teaching others how to make their first app, etc.
I'm sure we have loads of x-browser compatibility bugs, as well as known issues with respect to accessibility, absent localization, no great mechanism for contributing new components, and many more.
Oh, and the gamification bits in particular were really just testing the gamification APIs -- the levels we have in place are deeply unuseful =).
I bet. But this is part of the problem with many of Mozilla's products targeting the education space (Open Badges, I'm looking at you). Teachers, administrators, bureaucrats think they're the cat's meow. But (of course) they want nothing to do with the implementation details. But they do expect them to be usable.
"At the highest level, we're exploring whether it's possible to make a tool that lets non-devs (_not_ you folks!) who currently see their phones as a pure engine of consumption, as a place where they can create something fun or useful."
That's a fantastic idea. So are open badges. But "us folks" are the ones that (whether we work in edu IT, at an edtech company, or are fellow travellers) are expected to make these half-baked great ideas work, reliably, in the real world, for educators and students.
I'm not trying to rant. Mozilla has great ideas for education. But the poor (maybe I should be more generous and say incomplete) implementation of so many of these great ideas (Persona, Open Badges, and now Appmaker) is maddening when they're presented in a way that "not us folks" expect them to be available for production implementation.
We work in the open, up to and including staging pre-alpha software on public URLs so we can gather feedback in-progress.
In this case, we were showing this off in super early state at a company summit. Word of mouth appears to be powerful!
Get it working, I always need tools customized to a particular task that a simple app would solve.
Sometimes, the best tool is a hammer...
- opt out of the levels thing on first load, it's not ready. - instead, jump straight in the designer and run through these few steps:
- drag & drop a button, click on it, notice it sends out messages on the blue channel - D&D a counter, notice that it listens to a blue channel, and that the button clicks cause it to increment (that's how we "program" these components - D&D another button, make it emit on a different color, and configure the counter to "count down" on that color. That way one button increments, the other decrements
- D&D the fireworks component, configure its "shoot this many rockets" to a third color (and clear "shoot rocket); make the counter emit on that color. Enjoy the fireworks show.
- Other components that work well for understanding things are:
- ratings widget - input widget connected to a map widget will center the map on a place name (although HN will likely exceed the limits on our usage of the OSM server; need to setup another one =() - flickr widget can do both topic and location searches
Let us know if you have ideas for components we should build (or submit a PR!).
The publish button will create "hosted apps" which can be installed on FirefoxOS, Firefox for Android, and incidentally recent builds of Firefox desktop, although the focus for Appmaker is very much mobile apps).
I know you said firefox desktop was not the main focus, but I have a chrome packaged app that I'd love to port over to firefox OS
is there a good guide / overview of doing this?
Sure, it's a bit rough around the edges, but it is a brilliant thing for non-devs to play around with. With a little tinkering sround, I managed to create a simple chatroom app: http://truthful-week-478.appalot.me/install.html
Here're my first impressions:
1. The color flow as a broadcast-reception link is an interesting idea but not immediately intuitive. Once I figure out what it was for, I managed to blaze through it fairly quickly.
2. Broadcast trigger actions need to be clearer. For instance, I know there a trigger for the randomcat but the fact that clicking the random cat is the trigger isn't all that intuitive.
3. Make chaining triggers a thing? I know it's not as easy as it seems but some combinations do lend themselves to chained triggers. For instance, I wanted to emit the random cat to the chat room with each text (as a test) but there was no way to chain triggers.
4. Publishing the app seems to lose the custom name assigned to form buttons. The app I posted above should say "Clear Chat" where it says submit.
5. Allow me to save my apps under a custom name? And publish the changes to the same app after Edit? Not sure about the latter - haven't tried it yet.
Overall, it is a brilliant achievement for something that is pre-alpha or pre-pre-alpha! I'd like to see where this leads!
I am now heading back to construct a simple clicker game. Wish me luck! :D
EDIT: Both Chrome & Firefox seem to throw errors about a few js files (primarily ceci.js & designer.js) in the console while loading the page for the first time. CTRL+F5 solves it. JS caching issue, I'm guessing? :)
I am playing around with a Raspberry PI / Arduino solution and the PI has a webserver which relays commands to the Arduino. Now, it would be very neat to have a mobile app to trigger these commands. For example, pushing a button to turn a light on or off. As I do have minimal time creating GUIs, this tool, with the flexibility of a HTTP module, would be perfect to use for prototyping such solutions.
This could be used to trigger commands as described above, but also possibly for embedding content from other sites etc.
Probably not where you wanna go with this tool, but it would be neat for situations where you want a quick GUI to control stuff.