Why is there such a strong focus on "responsive" CSS? It has never made much sense to me, because my desktop will never turn into a tablet, and my tablet will never turn into a smartphone. It seems as though creating a better server-side abstraction that lets me produce different markup that shares much, but not all, of the CSS would be more effective from a development time perspective.
How do you make sure you support all the possible devices that will request a page from your server? If you divide between desktop and mobile, what do you serve a tablet? If you make a tablet layout, what do you do if it changes orientation? Once you added the tablet, what do you serve a web-enabled TV? A handheld console? A high-resolution display?
Responsive is about responding to container characteristics, instead of relying on the assumption that a certain known device has certain characteristics. Even with responsive, the rabbit hole goes waaay down, but at least you're avoiding the ghetto effect of "supporting" a set list of circumstances.
(Resize your window and you'll see how everything re-aligns for desktops, tablets, and smartphones)
I chose responsive css because I can code it once, and it'll work on all devices. No bloat, no separate versions to maintain. Why wouldn't you want that? Especially with more and more consumers buying mobile and tablet devices. You increase your potential audience with a few lines of css code. Why do it through server-side code and have seperate versions to maintain during each and every update? As long as you plan ahead, your design can be responsive with literally a few lines of css code.
Interesting that the tagline is Interface Builder for web sites. One of the big powers of IB is that it ties back into your code so directly. This seems somewhat separated from whatever underlying code I'm creating.
I think the killer app is really an IB-for-the-web that plugs into Rails/Django/Symphony/etc so you can start building a web app visually, without sacrificing code quality.
The great thing about building web apps is that it's extremely easy to connect the front end to the back end. By focusing our efforts on making the experience building the HTML and CSS great, we don't have to force a choice on you like Rails vs. Django or Backbone vs. Spine.js.
That's great for the initial build-out, but what happens when I want to change something? I can't use your tool anymore, because for me to move an element on the page means I have to take that generated HTML/CSS and start over again converting it to a view template.
This is a far-off idea, but it would be cool if you had support for various frameworks and could plug into a git repo to map the view data into the templates you're outputting. That way I could continue to use your product for the full lifecycle of development.
Right now I write everything in HTML/CSS by hand and poke around with Firebug to do anything visual with it. I'd love a live-edited version of my view templates with a visual editor like this that generates high-quality code. I would pay a sizable amount of money for such a service.
Perhaps Divshot could have some plugins that allow you to take the generated markup and specify, for example, which elements should repeat from an array passed through from Rails, or Django, etc. Then export that kind of code.
Export to HAML would also be nice.
Who is the target market for what you are describing though (or for divshot for that matter)? Is it meant to be for slightly less technical people? Is it meant to take over all development/developers in the future?
Being a seasoned developer, front, middle and back end, I find this an interesting product, but something that I would likely never use more than "playing around". I'm not trying to troll here, I'm legitimately curious if anyone else feels this way.
Edit: I did sign up for an invite over a month ago, and I am legit excited to give it a go.
We're building Divshot to be a tool that professional developers and designers use every day. I totally understand the "I would never use it for more than playing around" approach, but that's how it starts (see e.g. http://cdixon.org/2010/01/03/the-next-big-thing-will-start-o...). All I can say is give it a chance, watch how it grows, and I think you'll change your mind.
Right, but which part of the dev/design process is it taking over? Do you guys see divshot taking over production ready front end development the way Balsamiq (and the likes, arguably) took over pen & paper?
Given the predecessors to divshot in the WYSIWYG world, expect many developers and designers to be extremely open minded, yet very skeptical.
We definitely expect some skepticism given past WYSIWYG entries into the space, but we consider our prime directive to be "No matter what, the output is clean."
We hope to be a tool that developers will use to rapidly prototype an interface at the beginning stages of an application and then continue to use it to experiment or quickly build new functionality throughout the app lifecycle. Hope that answers your question.
I was lucky enough to use the Divshot beta several months ago during a hackathon, and my team's process was indeed to copy the generated HTML into Rails ERB files at the end of initial design. But what was really powerful was the ability to WYSIWYG our way through discussions about what our product would do, and then just publish easily consumed code when we were ready to hack. Our alternative would have been an analogous process in Photoshop (slower and doesn't produce the base code) or to iterate the HTML during the discussion (much slower and requires the designer/developer to switch mental contexts quickly). It worked very well for our purposes and I see it being invaluable during client discussions.
I'm still reviewing comments and sending out invites to new followers, sorry you haven't received one yet! We opted for a private beta in short waves so we can learn more about our users and address their early feedback. I wasn't able to find your email so give us a shout if you're still interested. Click the "Contact" link in the footer. Thanks!
We're following the exact docs for Twitter Bootstrap with regards to HTML output, and yeah it can sometimes get a little div-heavy. We will be supporting other UI frameworks as well as emphasizing semantic HTML as much as possible as we grow beyond Bootstrap.
A bit unrelated, but I wanted to thank Mark and @fat, I think the president of the United States and the governor of the Universe should personally award them for creating so many jobs throughout the world. Bootstrap created lots of opportunities for people, startups, established companies and everyone in between. I really appreciate the work of @markdotto and @fat making Bootstrap. You guys rock!
I'm right at the beginning of designing my templates for a Bootstrap/Django project, so this is a really great time to see this. I'd really like the ability to tweak the designs without needing to edit a text file and reload the browser.
Question: do you guys support custom Bootstrap themes?
(Oh, and I wouldn't turn down an invite. The email I signed up with is in my profile.)
We're not focusing on connector code at the moment because, as a tool for developers, we want to give everyone the ability to use their own frameworks of choice (Backbone or Angular, Knockout or Spine). Everyone uses HTML and CSS (or at least HAML and SASS), so we can use it as a common starting ground and help speed up the initial phases of development.
I've been dreaming of something like this for a while. There's an OS project called "Stylo" (https://github.com/maccman/stylo) that has the basic framework for an interface builder, but it's not as far along as what I can gather from the Divshot demo. I'd be much happier building web apps in my free time, instead of an app to build web apps. Looking forward to checking it out.
We're huge fans of Alex MacCaw's open source projects. Divshot is written completely in CoffeeScript and Spine. There are features in Stylo that we'd like to add to Divshot such as color pickers and more design options for the inspector (gradients, border radius, etc).
Lucky for you one of our key goals is that we will always export to clean, unencumbered HTML and CSS. Once you export from Divshot you can use the output in whatever tools you want without worrying about compatibility.
Secondly, we definitely want to support offline capabilities (as a web app still, but it's very possible) and the ability to safely store all of your work :)
The editor itself is completely static HTML and written in CoffeeScript/Spine which gives us a lot of flexibility. We're exploring different opportunities for integration and possibly a downloadable version.
This looks really exciting. This seems more like what I wanted easel.io to be. I had actually started working on a simple html/css in-browser editor to use for mocks that could be taken into production, but looks like this might be what I was looking for.
For teams where you have non-coding interaction designers and backend designers AND separate marketing teams this could be an awesome accelerator simply because everyone uses the same tool (Bootstrap) but interacts with it in different ways. That's awesome.
We're starting with Bootstrap, but it's a general tool for rapid prototyping and front-end construction for web apps. Bootstrap's the most popular UI kit out there right now, so we're starting there :)