The ditto was for the fact that web development still sucks after all these years. Sorry if that wasn't clear. As for faeries and pixie dust - I think you should have thought before you hit submit reply - that goes beyond contradiction.
My point is that web design is still stuck in a rut between coding and designing. My hope is that someone puts together a tool that lets enables designers to write clean code and create inspired designs. Trust me I've done my share of clean up of code. I've worked on teams where there are budgets for coders, designs, interface developers and marketers but not every job has that kind of budget. I have often found myself designing and coding. I know next to nothing about Sproutcore and my post may be of topic for this thread, but my hope for a tool that crosses the divide is shared by many in web design/development, if not by you.
It's coming along very very nicely, is heaps cheaper than DreamWeaver and is rapidly moving towards supporting HTML5. The more people we get supporting this one man project the better.
Admittedly I might be biased because I really love this application but with support for PHP, Ruby, and now basic support for Concrete as well as being able to develop with Prototype, JQuery, MooTools etc it's a brilliant app. It's standards based (currently slanted towards XHTML as opposed to HTML5) and has graphical editor as well as code editor.
There are still a lot of niggles because it's still in beta but it gets updated at least once a week. The more people we get checking this app out the more beta testing the developer can get and the more it can become better.
To me it just makes sense that a designer designs the layouts and the developer develops according to the layouts provided by the designer.
I don't think there's an argument here, that's the goal achieved by what mstone said.
Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.
So who does the middle step?
With current tools, you either have the designer slicing up the layout and building up the page in code/CSS to make sure it looks exactly like the design or you have the developer slicing up designs and laying them out, which wastes a lot of time that the designer ought to do as design work takes less time typically. In short, the designer is either doing some coding or the developer is doing some layout.
The holy grail is to have no middle step. Flash already offers this as a designer can throw shapes and animations onto a canvas without knowing one line of Actionscript code. Then simply pass the file over to a developer to add the functional code. That's how it should be with the designer doing design and the developer doing the code as you said.
We just need this for HTML instead of Flash.
Quote:
Originally Posted by lowededwookie
Then support Flux.
Flux looks pretty good but I'm starting to think that rather than have Canvas be another element inside the DOM, it needs to replace it so that all content is rendered in a Canvas context. Nobody (including developers) needs to see the markup for UI elements. Developers only need to click on an object and see the reference and properties.
The biggest problems arise from the flow of content and having to use floats, clears, absolute positioning etc. This should all be handled easily in a WYSIWYG fashion like it is when you position an image in Pages or Word and choose the layout type. Flux handles this ok but in apps like Flash there is no need to manually do anything about it.
I don't think there's an argument here, that's the goal achieved by what mstone said.
Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.
So who does the middle step?
Why would there be a middle step? If there's an issue the developer works with the designer directly so there is NO middleman at all. This is far more efficient as each have their specific role and work to the confines of that role. If the developer has an issue with the design he goes to the designer to clarify or try something else and if the designer has an issue with the code he goes directly to the developer.
A designer should never touch the code because it can cause flow on effects that the developer will have to find and workout what went wrong. The developer should never touch the design because that can have flow on effects for the designer.
The designer should only determine how something works in terms of the movement of the animation and NOT how it should work on a code level, leave that to the developer who will have a better idea of how the code should work.
Once again though all my comments are based on my engineering thinking so may not be the case in the "real" world which is an inefficient world.
Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.
So who does the middle step?
Like the guy/gal who does HTML/CSS didn't piss me off enough already.
If there's one more step there, it'll be a double homicide.
Why would there be a middle step? If there's an issue the developer works with the designer directly so there is NO middleman at all.
The designer creates a layout in either Photoshop or Fireworks. That's their job done.
The developer uses a set of PHP code or similar to interact with the designed page.
The middle step is where the images from Photoshop/Fireworks need to be converted to HTML/CSS. Like I say, if the designer does this step, they are coding. If the developer does it, they are doing some level of designing as they have to ensure the layout matches the original design.
This step shouldn't exist at all and it doesn't in Flash but it does in HTML. Without the middle step, the designer and developer are perfectly divided into their respective roles and live in harmony.
Quote:
Originally Posted by ihxo
Like the guy/gal who does HTML/CSS didn't piss me off enough already.
That's the middle step I mean. In your scenario, it would seem the designer is taking the role of building the HTML/CSS. It's more time-effective for them to do it but they typically don't know how or use naming conventions that won't fit with yours.
Imagine a situation where there is an HTML 5 design program and a designer uses the pen tools and layers and can even create animated objects as named assets. They just save that file and send it to the developer. The developer can then look at all the assets and reference them from code. Neither designer nor developer have to see any CSS code. The developer doesn't have the tedious process of recreating the layout all over again, they can just use it. This would save about 1 weeks work per project.
The open source SproutCore framework--which Apple invested in to create its suite of MobileMe apps--has been cross-pollinating with HTML5 features to develop in new directions, including a new interface builder, rich support for multitouch, and a packaging system for sharing JavaScript code between projects.
Apple should not silence the developers of sproutcore.
Apple surely know what they are doing.
Apple clearly wants to keep certain aspects of their roadmap a secret.
A way which is interact with two person with online apps and the the mobile web in general,
is about to change.
Apple didn't "silence a developer of SproutCore". Apple told one of it's employees to not make public statements on something he was being paid to do - that happened to be SproutCore. The employee working on the company dime part gives Apple every right to have a say in the message put out by an employee. Period.
Very true. In many ways, the more abstraction there is, the harder it is to find out why layouts go bad or functionality just breaks. Javascript is so bad for debugging as it is without relying on a codebase you haven't built to make it near impossible to find out what's wrong.
I checked out the demo of greenhouse and I had to install 11 dependencies to get the thing to run and it still doesn't work properly - maybe Safari can't quite run it properly.
Cappuccino looks good and has nice working demos like the following Powerpoint-style app:
but the apps still don't feel like desktop apps, generally run very slowly and use loads of CPU. Also, the integration with other web elements is still lacking.
I just can't believe that after all these years someone still hasn't made an application like Flash that uses Javascript for the API and SVG for the graphics.
You just shouldn't have to layout web pages using code. A designer should have a WYSIWYG workspace and be able to drop text with fonts and layout objects like scroll boxes etc onto a page, save it and then pass it over to a developer to add code functionality then simply publish it. No having to check various browsers for layout issues.
Ironically, Adobe is the closest to this now with the copy/paste to Canvas but you have to develop in Actionscript so there's still an awkward disconnect between the API and the published format.
hmmm... maybe you might take another look, if you're interested... That 280Slides demo is years old, and there are now vast improvements in all areas. Cappuccino is now moving towards 1.0, and Atlas is starting to not just look but be amazing. If you can spare the $20 for that, it's definitely worth it as well.
Seriously, anyone who thinks that web development hasn't changed in the last few years needs to go look at some of the tutorials and how easy it is to build something like 280Slides, without touching HTML or CSS.
Of course, the caveat is that all of the cappuccino stuff is strictly focused on web apps and none of it applies to traditional content-focuse web pages.
Comments
The ditto was for the fact that web development still sucks after all these years. Sorry if that wasn't clear. As for faeries and pixie dust - I think you should have thought before you hit submit reply - that goes beyond contradiction.
My point is that web design is still stuck in a rut between coding and designing. My hope is that someone puts together a tool that lets enables designers to write clean code and create inspired designs. Trust me I've done my share of clean up of code. I've worked on teams where there are budgets for coders, designs, interface developers and marketers but not every job has that kind of budget. I have often found myself designing and coding. I know next to nothing about Sproutcore and my post may be of topic for this thread, but my hope for a tool that crosses the divide is shared by many in web design/development, if not by you.
Then support Flux.
http://www.theescapers.co.uk
It's coming along very very nicely, is heaps cheaper than DreamWeaver and is rapidly moving towards supporting HTML5. The more people we get supporting this one man project the better.
Admittedly I might be biased because I really love this application but with support for PHP, Ruby, and now basic support for Concrete as well as being able to develop with Prototype, JQuery, MooTools etc it's a brilliant app. It's standards based (currently slanted towards XHTML as opposed to HTML5) and has graphical editor as well as code editor.
There are still a lot of niggles because it's still in beta but it gets updated at least once a week. The more people we get checking this app out the more beta testing the developer can get and the more it can become better.
Then support Flux.
http://www.theescapers.co.uk
Cheers! I'll check it out...
To me it just makes sense that a designer designs the layouts and the developer develops according to the layouts provided by the designer.
I don't think there's an argument here, that's the goal achieved by what mstone said.
Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.
So who does the middle step?
With current tools, you either have the designer slicing up the layout and building up the page in code/CSS to make sure it looks exactly like the design or you have the developer slicing up designs and laying them out, which wastes a lot of time that the designer ought to do as design work takes less time typically. In short, the designer is either doing some coding or the developer is doing some layout.
The holy grail is to have no middle step. Flash already offers this as a designer can throw shapes and animations onto a canvas without knowing one line of Actionscript code. Then simply pass the file over to a developer to add the functional code. That's how it should be with the designer doing design and the developer doing the code as you said.
We just need this for HTML instead of Flash.
Then support Flux.
Flux looks pretty good but I'm starting to think that rather than have Canvas be another element inside the DOM, it needs to replace it so that all content is rendered in a Canvas context. Nobody (including developers) needs to see the markup for UI elements. Developers only need to click on an object and see the reference and properties.
The biggest problems arise from the flow of content and having to use floats, clears, absolute positioning etc. This should all be handled easily in a WYSIWYG fashion like it is when you position an image in Pages or Word and choose the layout type. Flux handles this ok but in apps like Flash there is no need to manually do anything about it.
I don't think there's an argument here, that's the goal achieved by what mstone said.
Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.
So who does the middle step?
Why would there be a middle step? If there's an issue the developer works with the designer directly so there is NO middleman at all. This is far more efficient as each have their specific role and work to the confines of that role. If the developer has an issue with the design he goes to the designer to clarify or try something else and if the designer has an issue with the code he goes directly to the developer.
A designer should never touch the code because it can cause flow on effects that the developer will have to find and workout what went wrong. The developer should never touch the design because that can have flow on effects for the designer.
The designer should only determine how something works in terms of the movement of the animation and NOT how it should work on a code level, leave that to the developer who will have a better idea of how the code should work.
Once again though all my comments are based on my engineering thinking so may not be the case in the "real" world which is an inefficient world.
Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.
So who does the middle step?
Like the guy/gal who does HTML/CSS didn't piss me off enough already.
If there's one more step there, it'll be a double homicide.
Why would there be a middle step? If there's an issue the developer works with the designer directly so there is NO middleman at all.
The designer creates a layout in either Photoshop or Fireworks. That's their job done.
The developer uses a set of PHP code or similar to interact with the designed page.
The middle step is where the images from Photoshop/Fireworks need to be converted to HTML/CSS. Like I say, if the designer does this step, they are coding. If the developer does it, they are doing some level of designing as they have to ensure the layout matches the original design.
This step shouldn't exist at all and it doesn't in Flash but it does in HTML. Without the middle step, the designer and developer are perfectly divided into their respective roles and live in harmony.
Like the guy/gal who does HTML/CSS didn't piss me off enough already.
That's the middle step I mean. In your scenario, it would seem the designer is taking the role of building the HTML/CSS. It's more time-effective for them to do it but they typically don't know how or use naming conventions that won't fit with yours.
Imagine a situation where there is an HTML 5 design program and a designer uses the pen tools and layers and can even create animated objects as named assets. They just save that file and send it to the developer. The developer can then look at all the assets and reference them from code. Neither designer nor developer have to see any CSS code. The developer doesn't have the tedious process of recreating the layout all over again, they can just use it. This would save about 1 weeks work per project.
I bought two copies (one for gf) months ago but I haven't jumped in yet.
I'm still waiting on iWeb Pro from Apple.
Apple should not silence the developers of sproutcore.
Apple surely know what they are doing.
Apple clearly wants to keep certain aspects of their roadmap a secret.
A way which is interact with two person with online apps and the the mobile web in general,
is about to change.
Apple didn't "silence a developer of SproutCore". Apple told one of it's employees to not make public statements on something he was being paid to do - that happened to be SproutCore. The employee working on the company dime part gives Apple every right to have a say in the message put out by an employee. Period.
Very true. In many ways, the more abstraction there is, the harder it is to find out why layouts go bad or functionality just breaks. Javascript is so bad for debugging as it is without relying on a codebase you haven't built to make it near impossible to find out what's wrong.
I checked out the demo of greenhouse and I had to install 11 dependencies to get the thing to run and it still doesn't work properly - maybe Safari can't quite run it properly.
Cappuccino looks good and has nice working demos like the following Powerpoint-style app:
http://280slides.com/
but the apps still don't feel like desktop apps, generally run very slowly and use loads of CPU. Also, the integration with other web elements is still lacking.
I just can't believe that after all these years someone still hasn't made an application like Flash that uses Javascript for the API and SVG for the graphics.
You just shouldn't have to layout web pages using code. A designer should have a WYSIWYG workspace and be able to drop text with fonts and layout objects like scroll boxes etc onto a page, save it and then pass it over to a developer to add code functionality then simply publish it. No having to check various browsers for layout issues.
Ironically, Adobe is the closest to this now with the copy/paste to Canvas but you have to develop in Actionscript so there's still an awkward disconnect between the API and the published format.
hmmm... maybe you might take another look, if you're interested... That 280Slides demo is years old, and there are now vast improvements in all areas. Cappuccino is now moving towards 1.0, and Atlas is starting to not just look but be amazing. If you can spare the $20 for that, it's definitely worth it as well.
Seriously, anyone who thinks that web development hasn't changed in the last few years needs to go look at some of the tutorials and how easy it is to build something like 280Slides, without touching HTML or CSS.
Of course, the caveat is that all of the cappuccino stuff is strictly focused on web apps and none of it applies to traditional content-focuse web pages.