Most of the bugs is found and fixed. Now the big question is how it works under heavy load, cpu, file handlers etc. It became more difficult to develop than what I possible could have imagine. Everything on the server side is non-blocking, asynchronous and works in parallel.
My next step is to write instructions, build some new themes, blog about the development, how to use it etc… Check it out at: Appernetic.io
I don’t think you’ll get much feedback around here. I built something similar and posted for feedback but didn’t get any. I’ll try out your app and let you know. The UI looks pretty, so good job on that. Also are you running the hugo generator on the same server as the site is hosted?
thanks for your feedback. I only use the server for static Hugo site generation and then let the user push it to GitHub after previewing the site, because of caching. I’ll will check out your service!
Great job on the speed of the site, It is very fast. A few things which can be improved:
- Navigation is confusing, themes/images are under the publish button and
I didn’t find a way to upload images (I tried doing it from the markdown editor and was able to )
- The codemirror editor and the markdown editor are very nice. Good job on that.
My suggestion to you would be to get a new user and ask him to use your website and take notes on what stuff is confusing. The navigation definitely needs work. Other than that it looks like a really well made app. I wasn’t able to test out the deployed site because of an error in a theme though.
Thanks to Node.js and Redis it is fast. I also use Cloudflare as a CDN.
My idea was to have the dashboard clean and uncluttered with as little buttons as possible, therefore I put them in one drop down button group with the most used function “Preview” in the first place. The drop down is a problem in a mobile browser because the touch field is very little other then that it works, I think. Time will tell and what the majority of users think. For now I keep it this way.
The editor was very difficult to make it behave nice with upload and Angular in particular. I have evaluated, tested and digged deep in the code of many markdown editors and every time got back to PageDown. It’s not the best, fastest or most nice looking editor but it works quiet well. I am missing headline buttons and need to work on better list functions and also add shortcode functionality perhaps.
In the coming week I will have new users testing the site.
Yes it is annoying with error in many of the themes. Even though it is error messages, most of them still work when you deploy them such as hugo-icarus-theme.
Thanks for your input!
Lots of work now with instructions, faq, disclamers, pentesting, backup, maintenance, layout, support and blog articles…
This looks really cool. Excited to see these products emerge.
This might be just a me thing… but I think it’s worth saying. Had I not seen you here (as part of the community), I definitely would be a lot more put off by this:
Log in with your GitHub, Twitter or Facebook account. Creating a Github account is like signing up for Facebook or Twitter. You’ll give your name, username, email address, and set a password.
I get that, for the service to work, the github connection is needed. But to see a demo I have to give access to my Github, Twitter or Facebook account would make me uneasy.
For what it’s worth, I think enabling the demo access before log in would be better. I would just require log in / sign up where there is a need, or just have your own sign up system that is not requiring the user to give potential access to their personal services / data.
I was going to try the service. But I am one of those people who won’t give access to my data where it is not clearly required.
yes, you have a point there and the full right to be worried about giving access to your data.
First, the service only get access to:
- basic profile (users public profile)
- email address
- public repo (read/write)
Nothing else, no password, no private info. You will see this when you login and you also have to confirm it when you give Appernetic access to your GitHub account. Maybe it is too much for the demo.
When I developed the service I did not consider having a demo, so as an afterthought the easiest thing was to keep the login but use my GitHub account in the back-end. It also feels safer for me to know who is using the system and I do not have to check the published site all the time for content that is not following GitHubs guidelines, which will be a big problem with no login or unverified accounts. This way I have only serious users.
I also thought that it was more convenient for the user who doesn’t have to register or sign in again if he decides to subscribe.
If I use my own sign-up system I have to maintain a database, send out email confirmation and have a way for users to reset passwords.
So my solution was the best I could think of, faster to develop, safer for me and the service and GitHub, convenient for the user and the user is not giving up sensitive information.
I will have to think of a good solution for this, but I think it will be difficult.
Sure, and not saying I have a great solution to this (as not wanting the DB, etc is understandable given where we are). My suggestion would be to have the demo available without sign-in, and lose the Facebook / Twitter options (as I think there are enough that might be put-off by priivacy concerns because they are there). But just a subjective opinion which may not be how most others see it.
Thanks for kicking my ass!
I have implemented Auth0 Database connection, so users can now signup and login with email and password. This is the best solution I could think of.
I keep the other sign-in options, the more options users have the better, I think.
Ha, I wouldn’t describe it as that. Maybe just some left over jealousy from having really struggled to get php to work nicely with github when trying to create a way to transfer files automatically.
Sounds good though. I fully intended to test the service but haven’t got around to it yet.
I couldn’t stop thinking about the problem, so I had to try to solve it. So yes it was a positive kick in the ass!
Glad I could be of service. You don’t like PHP, or because of node.js easier command line use?
No I don’t like PHP. I don’t like the syntax and I like it less now because of its flaw/density ratio as the most riskiest programming language after Coldfusion and classic ASP.
With node.js and angular.js you can build anything and there is a large community.
Though I think PHP’s security flaws are more to do with the overuse of poorly made cms systems (built like Lego with loads of modules), and lack of regular updating.
(I’m not really qualified to argue on this one as I only know node.js as a desktop tool and am not up to date with the newer tools of either technology)
EDIT: by ‘poorly made cms systems’ i mean the way they are used and offered to clients, not the job done by the cms development team.
Yes, and often the client doesn’t want to pay for system maintenance and security.
We just shipped a new freemium version of our static website generator: https://appernetic.io
The only thing that is crippled is how many times you can publish each week, which is seven at the moment.
Give it a try!
For free I’d say seven is generous. Not had chance to try it, but will
I hope it will give users enough times to publish. It could be 5 or 14 also. Don’t know yet, no feedback at the moment.
I have now developed a Hugo Theme Showcase gallery with a simple one-click cloning.
The aggregation of meta information was no light task to implement. I have written a Hugo blog post about it: https://blog.appernetic.io/2016/05/27/appernetic-theme-showcase-gallery/