I can't tell you how happy this makes me. Let's talk!
To answer your questions:
"This will load up my grunt server automatically based on the latest push to github"
Almost - we'll serve the build directory that your gruntfile creates. We are thinking about running your grunt or gulp tasks for you, so that you don't have to commit your builds to git. I'd love to hear more about your setup and see what we can do to make it work.
"I can then annotate that HTML/CSS front-end to my designer for feedback changes."
Yes.
"No more screenshotting for me?!? This would be amazing."
Yup, that's the idea :)
"Any chance you can integrate to Bitbucket? :)"
We want to. Signup or email me at brendan@awesomebox.co and let's talk.
Great question - here's a few problems that Matt and I have encountered with Github issues and screenshots:
1) Clients, managers and other "non-developers" usually don't have Github accounts. When we tried making them use Github Issues, most of the time they'd use it for a week and then go back to emailing us or just stop giving feedback.
2) When new code is pushed to Github, how do you show non-developers? Usually this requires maintaining staging servers. What if you want to show different things to three different people? Three servers to maintain. With Awesomebox, you don't have to worry about this - we could even send them notifications to check out new versions, so that you don't have to bug them.
3) It's hard to keep screenshots and their associated conversations organized - it requires a lot of discipline, and when building things I've found that I tend to lose track of UI/UX feedback overtime, even if it's within an issue tracker.
4) Not all feedback is an "issue" or a bug. Github Issues are great, but are designed to track problems, not to help people discuss ideas or provide positive feedback.
I hope that helps answer your question - just a few of the reasons that Matt and I started working on Awesomebox. I'd love to hear more about how you work with people who aren't developers, and if our product doesn't fit your needs, tell us what we could do better. Feel free to reach out - brendan@awesomebox.co
I tried to register, and when I get the email and try to fill out the last 2 fields (username and name) it tells me my email address is already taken...not sure how that is possible...
Looks great! Tools usable by non-developers are often also more useful for developers, and that looks like the case here.
Any plans for Gitlab integration, either through Gitlab webhooks or a standard post-receive hook? All of my (and many other developers') private repos are privately hosted in Gitlab. I would be happy to help if needed to patch Gitlab and make this work.
Also, what about getting information out of Awesomebox? Will it post via webhook to another service?
Our goal is to integrate with your source control, no matter where it's hosted. Anything that can send us a webhook should work just fine - just a matter of timing for us to build the integration. Email me at brendan@awesomebox.co and let's talk.
As far as getting information out of Awesomebox, you're the first person to ask - what type of information would you want? There's a few use cases we've thought of, but I'd love to hear your ideas first.
There are some massive and unsolved engineering challenges to going beyond HTML/CSS/JS, but in an ideal world we'd love to make this work for any app, including native mobile apps.
Thanks! Let's take a stab at getting you setup with something small tomorrow ;)
It's funny that you said that about our landing page, because before this, we were probably the most egregious offender of having landing pages that didn't convey what we did. Takes a lot of work to find the right words and presentation, and we still want to make it better.
Thanks for the questions - totally understand the concern, and sorry for not conveying this more clearly upfront.
We ask for permission to manage your contacts so that you can easily invite co-workers to your project on Awesomebox.
We ask for permission to access your repositories on Github so that, for the repositories you choose, we can automatically update Awesomebox when you push new code.
Unfortunately, Github's permission model is "all-or-nothing" - we wish we could let you grant us access only to a specific repository, but it's not currently possible via Github's API.
If you'd prefer not to connect your Github or Google accounts, you can also signup with an email address and try using Awesomebox on an example project.
This question needs to be answered. It is NOT ok for apps like this to request blanket access to manage our contacts with no explanation. Edit: Thanks for the explanation.
Completely agree - our apologies for not making this explicit. See my answer above for why we ask for the permissions we do.
Part of the challenge is that, during the auth dialog, there's no way for us to explain why we're asking for permissions. This is true across every oAuth identity provider I've done integrations with - they don't give you a way to explain why you ask for something like "Manage Contacts".
For that reason, when we ask you to connect to Github, directly below the button we link to a page about security (right now only visible to logged in users, sorry about that):
What is it with requiring at least 6 character usernames? Why does it matter to an automated system if I use less? I get that a username with only one letter isn't optimal, but I don't see why it can't be > 3.
This has to do with keeping some words reserved or just off-limits. For example, some 4-letter words would not be preferred as usernames, as well as things like login, auth, etc.
Right, so make 5 the minimum then and reserve certain words. I guess I can always use usernames such as "administration", "dashboard" or "profile", right? I believe setting a minimum of 6 letters is a questionnable approach to this problem.
Totally understandable - we don't want to exclude you based on the number of characters in your desired username. We just don't have a good set of all the words we need to reserve upfront - what we really want to avoid is ever forcing someone to change their username because of a conflict like this.
We'll see what we can do to allow shorter usernames without ending up in this situation. Thanks for the feedback.
Awesomebox only works with client-side code that runs in a browser - HTML/CSS/JS. If you have a Rails app that serves up a "single-page" app (like Angular, Backbone, Ember, etc.), we can work with you to make Awesomebox work. If this applies to what you're building, email me at brendan@awesomebox.co and we'll do our best to get you running with Awesomebox.
In an ideal world, we'd be able to support literally any application - Rails, Django, even iOS and Android apps. But in order to make your code available without spinning up complex environments and rebuilding parts of Heroku, we're focused on people building client-side javascript apps that send and receive data via APIs. This category of apps is growing incredibly fast, and we think there's a lot we can do to help, as both Matt and I have spent the past year working in Backbone and Angular.
1) I mockup the design in Balsamiq
2) My designer creates the design in HTML/CSS and then pushes to git (using grunt/node/bower)
3) We screenshot and annotate using InvisionApp
4) repeat 3 and 4 until design looks good
If I understand correctly:
- This will load up my grunt server automatically based on the latest push to github
- I can then annotate that HTML/CSS front-end to my designer for feedback changes.
- No more screenshotting for me?!? This would be amazing.
Any chance you can integrate to Bitbucket? :)
EDIT: If so, please get in touch - happy to be your early evangelist and provide more feedback.