What is Reddit's opinion of Cloud Cannon?

From 3.5 billion Reddit comments

Definitely not. I'm using Polymer right now. Polymer is just a way of using webcomponents and the Shadow DOM with polyfills for browsers that don't support it yet. Yes, you can build full apps with Polymer, but that's just because they have a lot of pre-built components you can use that make it possible.

I'm betting SVG / CSS. Here is a cool breakdown of how some of the icon animations are done.

http://cloudcannon.com/

You upload your already made site and add class="editable" to whatever elements you want the shop owner to be able to edit.

It works off of Dropbox so they can just drag files to their Dropbox folder on their PC to add photos/files.

There are CMSs that are designed to be retro-fitted.

• Perch is the market leader.
• Couch is cheaper or free if you advertise them.
• Unify is another.
• CushyCMS is similar, but the CMS side of things is hosted by them. That makes it easier to set up, but I guess if they go out of business you're fucked.
• Cloud Cannon is similar but Dropbox based.

I've mostly used it manually with a CI setup which auto-deploys whenever I commit to production branch.

Had a quick look at this the other day and looks alright: http://cloudcannon.com/ (you can whitelabel it for clients)

There are differences between them, some allow custom plugins for example.

CloudCannon lets you upload your HTML/CSS/JS files, add class="editable" to elements that you want editable, and have your client visit domain.com/update to edit them. Content is edited in place, on the actual site. No database.

Disclaimer: I'm part of the team. I generally avoid promoting our company on reddit. However, in this case it does exactly what you have asked for.

Cloud Cannon http://cloudcannon.com/ - This is excellent for simple sites that you want to give your client an easy way to update specific content. I've just started using this, so we'll see how I feel in a few months.

Then I think the poster who said "get a better job" probably has your long-term answer.

Training and supporting the client are of course part of the project (and should be figured into the costings) but some things aren't possible, and some people just can't (or won't) learn this stuff. I use Jekyll for a number of personal projects, but it's completely unsuitable for [most|all] clients. If your company has made this decision and left you to clean up the mess, well you're in a position you don't want to stay in!

Videos are good, but some people just hate them so you can't provide key information only in that format. Video is great for being shown things for the first time, but they suck for going back to quickly check if you have something right. You need written materials too, covering what's in the video, but also you can have bulleted instructions and checklists for the client to refer to when submitting a post (because he will forget each time).

Another possibility would be to knock up a web form for them to submit their blog posts to you, to make it harder for them to screw it up. Form fields for metadata, and a Markdown editor with preview - there are loads of these on Github. Then when the blog posts are forced to come in in a consistent manner, you can automate things on your end, or at least polish your workflow so it only takes a minute.

Are you familiar with CloudCannon? It's a Jekyll hosting solution that's designed for your use case. If you don't want to make use of them, you can at least steal some ideas on how to make things harder for your client to screw up.

It's most definitely a challenge, but yes it's doable.

1. Wordpress-like ease of use can be achieved with CloudCannon. It's as simple as adding a class name to particular elements for you, and as simple as dragging and dropping stuff for your client.
2. That's the tricky part, but I believe you can do something with Snipcart? I can't vouch for it as I haven't used it, but you can have a read through this article for more information.

You are certainly poking at the challenges of static sites, but you do gain benefits on performance and speed – which may be worth it in the end.

I'm using Jekyll for my personal site and several web apps. I'm not using the blogging part, but it works best for small sites and blogs. The drawback is certainly the CMS part of it, so it might not be ideal for your project.

However.. CloudCannon offers a killer CMS system that works really great with Jekyll. This bit of JekyllConf (05:03:14 if the timestamp didn't work) seems to explain the menu bit you mentioned.

CloudCannon, as you mentioned static sites. Hopefully you wouldn't build it from scratch on this platform, but if you have a basic setup, you can edit the files in the browser.

http://cloudcannon.com/ is great. From your static site, you just add a class to elements you want the client to be able to edit! They edit the text inline. Has quite a few other features as well.

You really should take a look at Jekyll. It does blogging. Give it a bunch of text files formatted in Markdown with a YAML front-matter block at the top (you can create a template for this, BTW), and Jekyll will generate a static website with a blog.

Granted, Jekyll itself is mainly for techies like us, but there are services like Cloudcannon that provide CMS-like functionality on top of Jekyll so that non-developers can write posts.

As for ecommerce, you can always deploy one on a subdomain. For example, if I had a static site on asuraemulator.com, and wanted to add a shop, I'd fire it up at shop.asuraemulator.com.

I love Hugo for its speed, but you'd have to be quite capable at Go to do anything complex (which isn't insurmountable), but Jekyll has a great community, lots of plugins, avid maintainers and a base-case free-hosting (Github Pages). It's very capable.

But, most importantly, because I do client work and clients need a good editor/cms. This works with Jekyll: http://cloudcannon.com/

That might change in the future, but a great thing about most of the file-based static site generators is that they're very portable between one and another.

Try adding CloudCannon to your idea for using Jekyll and GitHub Pages.

CloudCannon basically provides a online, client-facing, CMS to a Jekyll site. You can connect CloudCannon to GitHub for version control and hosting on a GitHub Pages branch.

I think this works really well.

http://cloudcannon.com/

Actually... You don't gain any time or ease of use in terms of client experience. What you gain is a CMS that makes it trivial to develop and iterate on at the structural and design level. Jekyll is ideal if you want to be able to easily maintain a consistent website development cycle. It also has no real hosting dependencies. So there is no database or software to upgrade or secure.

For me, the biggest advantage of Jekyll is having all source material (including data and content) in simple flat file format. This makes every element accessible and local development seamless.

When I comes to clients updating their own site... I started charging them a regular maintenance fee and I make content changes for them. I was shocked at how much they value this as a service. And… To be honest… Because I'm involved continuously with their site I'm able to provide better value. I'm much more creative and better informed about how to implement their content changes. This strategy has actually allowed me to more than double my monthly profit on the same accounts. As a developer, it's way easier for me to update some flat files that I push up to a github repository then it is to use some WYSIWYG website editor interface.

However, in situations where clients do need to update sites that I've developed using Jekyll, I just use CloudCannon. It provides a great, easy to customize, client interface for updating Jekyll sites.

http://cloudcannon.com

Try making a few sites with Jekyll, hosting them with GitHub and GitHub Pages, and linking the site to CloudCannon. I think you will see why it really appeals to small web developers and technical teams.

>Octopress' author tells people "what's wrong with Octopress" at the Octopress' font page

So you like being lied and have the cons hidden under the carpet? Nice.

Here, these guys are selling their product, so they probably wouldn't let you know which faults they have but instead will try to convince you they are the top of the best.

Yeah I agree, generating the same content each request seems so redundant when the alternative is just serving a file.

Here's our Netflix case study for the site. It's a little specific to our platform but should give you a sense of what you can accomplish with Jekyll.

Have you looked into solutions like CloudCannon or CushyCMS? Both great tools and super easy to use! I have clients that are very happy with how they work.

By "placeholder", I mean something like this. The idea is that it's better feedback to show the user that something is loading rather than present her with an interface that is actually a fake one. Imagine if while facebook loaded, you could see all the buttons, but nothing happened when you clicked. How annoying would that be?

On my crappy connection, sometimes FB needs up to 30s to load (partially!). If I was able to see all the buttons, but nothing happened when I clicked them, I'd reload the page, or assume FB is broken and go away. By showing me obvious loading gifs, I'm aware of what is happening.
The nice UX touch of Facebook is to replace the traditional spinner with a lookalike of the interface, a wireframe of sorts, which allows me to begin parsing the information and understand the architecture of the page though content has not loaded yet. In a sense, I'm "active" on the page before it fully loads, but in my brain, not through my mouse/touchscreen.

To express myself more clearly, I am not discussing the speed of canvas rendering (though rendering on the server for a website with a lot of hits would be a matter of concern to me), but the actual experience you would be providing. My argument is that it would actually be, maybe counter-intuitively, a worse experience than a regular spinner.
Hiding state for the user to provide the illusion of speed is commendable, but not when it is misleading.

Again, I do not know what exactly you're trying to do, so maybe I'm off-base with what I'm saying.

As for rendering as SVG, it is imho a better fit for react (obviously), but it won't render in IE8, and you will get no CSS transforms on SVG elements, which might or might not matter to you.

Yes that can be done with CSS, but the work involved in timing and positioning those animations could easily end up taking more time than building working prototypes of the actual site. If you're still interested in this route, here are some examples for inspiration:

https://www.firebase.com/

http://mailchimp.com/

http://cloudcannon.com/ (this one uses an embedded video, so it's not quite the same even though it looks the same)

Honestly all hosting online starts at about $10. Some offer $5-8 but all of them average about 8.

Though...

http://cloudcannon.com/

Might be an option, regardless they're also $9 for the main features.

You could use the gradient generator that the others posted and then use the scroll handler from http://cloudcannon.com/deconstructions/2014/11/19/pixelapse-blurred-image-deconstruction.html but instead of changing an image opacity change the background position.

I'm the CTO of Cloud Cannon. We make it so you can go from a HTML website to a live site integrated with a simple CMS in 60 seconds.

What are the must have features of the CMS you want?