This question has been asked before somewhat, but I hope mine differs. My situation is I have been a desktop developer for 8 years (winforms and silverlight, also ios). More and more web contracts have been coming up for me but I have passed on most because they cause me more headache than what they are worth. I have just completed a dating website for a client in asp.net mvc. My problem I really have is with the development of the actual webpage layouts. Something that would take me minutes on the desktop equivalent would take me hours in the web, trying to align everything correctly so that it would look correct.
If I could streamline page development my web development would be 100% better and quicker. Can anyone give me any tips/advice? Coming from desktop development where you would drag and drop items on and anchor them accordingly.
I dont know if Im missing something or whether my heads web layout space, its in the desktop layout space. HELPPP!!!
Thanks in advance
Well, one BIG difference from desktop to web is that you are at the mercy of (so-called) standards.
in desktop development you know and expect consistency of rendering on the client - and thats why drag and drop, pinning, auto-resizing (of all elements!) is as expected 100% of the time. Your settings are in fact set - "set and forget".
on the web, you have to contend with whatever browser your user is using, what it can handle as far as "standards"
That's why it takes more effort and a mixed bag of tools to get to some parity across possible clients to your application.
So that's why really knowing code (instead of "design view") matters a lot - and it means a lot of effort as well. As time goes by though, you'll come up with your "trusted toolkit" and create your own (or use readily available) code and/or design libraries/templates (JQuery, 960 grid and similar, and a whole lot more).
And that's just talking about the front end.
You'll have to understand the "stateless nature" of the web/http and have to figure out how to persist data - you do this too in desktop dev, but its a little more fragile when it comes to web.
On the back end though, if you have a mature framework (i.e. .Net) you can have a lot of code reuse.
The "open" nature of the web has its pros and cons, and while the web has gone quite a long way to "mimic" the desktop, that term (mimic) says it all as well.
You'll also find "religion" on the web, and its rarely a good thing. I'm sure you've heard of this very mature technology called Flash and well, it seems that its suddenly out of favor - all because of something called iPxx :) A mature technology that has had more than a
decade of growth. Apparently "plug-in" is evil now (hint, Silverlight is...)
The replacement? HTML5 and Javascript and CSS which is graduating from mere styling to include things like transforms and transitions - not sure if that's a good thing - seems separation of concerns (MVC) goes out the door (but who am I to judge) ...which is in its infancy - don't get me wrong I've seen amazing things by the bleeding edge gurus - but bleeding edge it is and to avoid rambling, going back to my first point, subject to, yes, so-called standards of different clients (browsers, devices, etc.).
So yes, it's an exciting time to be sure. So as the saying goes, "stay young, stay foolish"...and never stop learning.
Well, there is no definitive guide to switch perfectly from desktop developement to web developement but there are some tools which will help you to accomplish your goal.
The best (and most expencive) tool would be to use dreamweaver:
http://www.adobe.com/de/products/dreamweaver.html
But be aware, sometimes, the html looks ugly. This could be the best practice. Build some designs with a tool and modify the html code to your likes.
Related
As a new to web development i wonder, where should i start learning.
Should i start from a big good book on HTML5&CSS3 and hope, that FF and Chrome will support what i do, OR the whole world novadays doesnt write CSS themselves, and use help of JS-based CSS frameworks?
I think i wont be able to do a real world website in a year, so we must keep it in mind.
I hope, with modern browsers bit by bit support of new futures of HTML&CSS, many things can be done by native CSS3&HTML5 to the moment i 'graduate' w3school:)
If you are new to web development, I suggest you stay away from CSS frameworks and concentrate on "basic" HTML, CSS, and JavaScript. It is surprisingly easy to make a "real world" website with these basic tools. The whole world does NOT use CSS frameworks, most web designers do write the CSS themselves.
The best way to learn is practice. I would find something you are interested in and use that as a project to work on. Show off your knowledge and talent with whatever you are into!
You should be aware it will be many years before HTML5 and CSS3 are supported by all browsers, I expect that many will stick with IE8 for a long time since IE9 won't work with XP.
you should start by getting a little project. Make random sites. Pretend you got a webdesign studio. Look at other sites. view their source. Get your hands dirty. W3schools is your best friend.
start with html,css then add javascript(jquery) then go serverside. you could do this backwards too.
thats how i started.
my 2 cents.
HTML and CSS are very simple. Being a good developer is having the experience to know how things work and when to apply what.
On the other hand jQuery is a library, thus like a real life library you are always reading. Learn how it works, and then learn to google regarding what you are looking for.
Don't skip ahead to HTML5 and CSS3, that's a lot like starting with a beta product, they are not yet standardised, but have been adopted (thus far) by the browsers.
Analogy
A very good developer is a cowboy with his hand at his holster ready to whip out the perfect bit of code, due to experience and practice.
The novice has to get his gun out of bag, clean it, load it and aim it . As long as you are not going up against an expert your fire eventually, just hang in there.
P.S. Nearly forgot, the only point of framework ultimately is to increase the speed at which you can develop. If you don't know how it works it will only slow you down, and you don't need that on top of everything else.
I'm about to embark on my first attempt at Desktop Software Design and I wanted to know any similarities behind the core principles of Web design that i can take with me or differences or books or articles etc?
Any help greatly appreciated.
As mentioned many times here on SO, "Don't Make Me Think" by Steve Krug is an invaluable resource when it comes to usability and UI design.
I'm just going to throw one tip out there for you to keep in mind that I've found different: desktop apps should be responsive. Users on the web are somewhat acclimatized to wait for seconds for their action to take effect (well, not we SO readers, cause we're using the good stuff :-), but you know what I mean). On a desktop application, that wait can seem interminable, and especially unforgiving is if you lock up the main event loop while processing data for several seconds. Even repeated delays on the order of hundreds of milliseconds can make your app feel sluggish. Use threads to keep the UI snappy, and make sure scrolling and loading operations are crisp. Load lazily or incrementally if necessary.
I've been told that one of the most important things to keep in mind in web development is that you cannot rely on the user viewing your application in any particular browser. In particular, different browsers handle different window-sizes and screen resolutions differently.
For example, fixed-width versus variable-width pages are a constant concern in web development because of how different machines and browsers handle them.
Moving on to desktop software design (WinForms?), you will have much more fine-grain power to control the appearance and user-interface of your software.
But remember, young Peter Parker: With great power comes great responsibility!
I've chosen Flex 4 as the most appropriate technology to develop a graphically-rich web application (its not a simple content-driven site), but worried about how the recent negative press (i.e. security issues) may effect end-user's trust and ultimately whether the user-base may drop promptly in response. (I don't care if my app works on iphones or ipads for now)
I think Flash Builder 4 is an great development environment and has minimized development time for me/my team. After some basic testing of graphical animations similar to that used in my app - HTML5 didn't perform as fast, is inconsistent with browsers, and some animations are jagged (I expect browser performance and graphic libraries to improve over time). I also 'personally' dislike programming Javascript as I am very fond of strong-typing to uncover mistakes quickly.
If you develop Rich Internet Apps, how are you responding?
Are you preparing to potentially migrate to HTML5/Javascript? Java? No action?
BTW - I don't want pro/anti-flash arguments - just curious to see how the community is responding.
At the end of the day, Flash/Flex aren't going anywhere. If Flex 4 meets your current needs and you're aware of the limitations (ie can't deploy to iOS devices) then I say go for it. Yes it's true that the topic has become mildly politicized - but if you're offering something your clients need then they'd be silly to refuse to use it on the grounds that they support "HTML 5" - when HTML 5 clearly doesn't offer you the tools you need.
Plenty of awesome stuff is coming down the pipe in Flash, much of which simply can't be done any other way - google UJam for an example. I wouldn't let Steve Jobs scare you away from using the technology that works for your needs.
My company plans to continue with Flash, using FlashBuilder 4 and Java back end. We went with Flex/Flash several years ago to get out of the business of supporting all the different browsers and into the business of being productive and giving our users a rich client-side experience.
HTML5/Javascript have potential, but are nowhere near as robust, powerful, fast, or efficient. The class hierarchy, data typing, and event model alone put ActionScript 3 miles beyond any Javascript. So what if Steve Jobs gives Flash the thumbs down? Time-Warner and other big media companies have said they're going to continue with Flash, so it's only a matter of time before Steve Jobs either relegates Apple to permanent niche status or caves and allows Flash on Apple products. (My guess is for the immediate future he will prefer niche status to admitting he is wrong—look how long he maintained a mouse only needed a single button?—but that's just my opinion.) In any case, Flash will soon be available on a multitude of smart phones, including the Droid, so I am not worried.
Adobe will provide tools to convert to HTML5, but they are already following the HTML5 Path with some introductory tools. Just keep watch on adobe. They know what is going on. They just killed mobile flash so even though they argued with apple over it they finally did the right thing instead of stupidly holding on to it just because... hope that helps
I'm a Flex developer, but I think HTML5 is going to be huge. The full features of HTML5 are years away, and I don't think it's totally going to kill Flash. Flex will hold on to some part of the RIA market because it has a lot more going for than just a de facto standard client plugin -- LCDS/BlazeDS, plays nicely with ColdFusion and Java.
I like Flex for the long run. It'll lose some ground to HTML5, but there are areas where Flex will hold its advantage.
Disclaimer: I am author of Web Atoms JS
Flex/Flash is dead already, as usage of non PC devices is increasing everyday. Except old IE (IE<10) almost all features of Flash are already offered by browsers. File API, AJAX upload with progress bar,Canvas API, Indexed DB, Cross Domain message API & Web Sockets. And CSS3, WebGL with 3D can give flash like graphics.
Regarding Component Library & Binding, HTML5+JS lacks component driven development that flash offers. To bridge this gap, we created framework that gives similar functionality with all components to that of flex. Look at following image & see this blog which outlines similarities between Flex & Web Atoms JS.
http://akashkava.com/blog/439/migrating-from-flex-to-html5-with-web-atoms-js/
Here is link to documentation.
http://webatomsjs.neurospeech.com/docs
This is a best-practice topic.
I saw it as a prefer method for some web developers. Instead of doing the CSS layout from scratch, they start a photoshop mockup first and then decode it into CSS.
What do you think about this approach?
Best to all,
Mockups are great, but I don't know if photoshop is the very first thing you'd want to try for the purpose -- at the very start, when you're just trying to get a logical layout for the various pages of the site (before refining it in terms of looks &c), a whiteboard with dry-erase markers and post-it notes affords for very fast, repeated mock-up rearrangements for the early brainstorming. Once there is some reasonable agreement on one (or a very few) possible arrangements of information, then visually more accurate tools enter into play.
BTW, just don't forget to photograph the whiteboard before changing it (any decent cellphone will do, you're not trying for high quality here;-) any time there are ideas or suggestions you may want to revisit or ponder in the future!
It is fast. This is why i always use this method. You don't want to spend the time building cross-browser CSS until you are actually set on a layout.
Most webdesign graphic artists work this way.
Many programmers simply find it a waste of time.
It has advantages, and disadvantages.
Advantages:
Many graphic artists grok photoshop/illustrator more than they do dreamweaver.
Customer gets a preview of the final product that works everywhere: mac, pc, firefox, ie, safari, whatever. Sending an html preview in early stages of production with developers using firefox and customer using MSIE always stirs up trouble.
And don't think to be on the smart side, scribbling MSIE driven html. Starting with non-standard html and converting to standard is more painful than doing it the other way.
There's one more catch: many web site customers tend to have a Mac and use Safari. Web committents tend to have a stronger taste for graphics than the average, so the chance to bump into Mac maniacs is higher in this sector than in others.
More design alternatives can be prepared spending less time on each one. This could be a dramatic advantage while dealing with murky clouds of executives with no designated decision-makers on the customer side. Alternative mockups will be passing hand-to-hand until general consensus is reached on one design or the other.
Disadvantages:
"Cutting" the graphic design into html becomes an additional work and it's not clear who's gonna pay for that extra time.
It favours graphic-centric, and rigid, design workflows. Customers agree pre-emptively on a given preview and that's what they get by contract. Every graphic modification means money, behaviour and programming instead tend not to be well defined, or worst, ill defined by the mockup.
The quest for pixel perfect cross-browser adherence to the mockup may drive you insane. If you agreed on a given rigid design with the customer, that could become a dire issue to pursue.
Dirty CSS tricks shoe in into your design. Using an HTML mockup, the customer would have approved a design driven by code with less tricks in place.
Anyway, I wouldn't suggest photoshop for a mockup, but inkscape. (or illustrator, if you worship adobe by burning piles of money into magic circles at midnight)
A scribbling stage is good too, while discussing the contract live with the customer.
I prefer pencil and paper to felt-tips, and I webcam shoot ideas for archiving and email forwarding. When it comes to scribbling, anyone does what feels more natural.
Not doing any and rely onto sample site examples and screenshots for graphical reference is always an option.
If you're productive that way, why not? Not everybody manages to envision their Web site perfectly as they're typing in a bunch of angle brackets.
More seriously put: It's your job, so it's your responsibility to do it in a way that allows you to do it effectively.
When prototyping, it's important to choose the right fidelity. This article from BoxesAndArrows provides a nice introduction to the various options and their uses.
I particularly like this line by Bill Buxton which the article quotes:
There is no such thing as high or low fidelity, only appropriate fidelity.
In this TechTalk by the Facebook Design Team, they mention how they use Photoshop in their design process (IIRC it's somewhere midway through, but I can't seem to forward through the video).
I am a web programmer who knows html and css fairly well. I can use a graphic program for it's basic functionality, but desinging a complete graphical web site is not my thing.
I let a graphic designer use his or hers graphic program to create a nice looking layout, and than code the website by hand in html and css.
It works for me, and gives my customers a design they like (cause a graphical designer will always make a much more nice looking design than most web programmers).
Agile methodology would suggest something easily modified in consultation with the customer. Dave Thomas in Agile Web Development with Rails suggests scribbling on paper. But anything has got to be better than chipping away directly at handmade CSS unless you really know what you want.
I was thinking about saying "scribbling might not cut it for a formal presentation" but the awesome SO crowd beat me to it in the comments...
Personally, and at every webdev firm I've worked at, I've always mocked-up in photoshop first. Jumping straight into CSS and markup is more of a bottom-up approach and makes sense to a lot of programmers but in web development you have to keep in mind that there are aesthetics to consider and a creative direction to follow. It's not enough that your product is functional, it needs the input of a professional creative-director/graphic-designer in order to make the product pleasant to look at and use.
In my experience, the problem has always been wrestling with inflexibility of team-members. Graphic designers who are aesthetics focussed and refuse to compromise their design integrity; which sometimes results in impossible or extremely difficult and un-semantic layouts. Developers who flatly refuse to compromise the integrity of their code where there is a workable solution - which might be a little less elegant. The key is to have a creative team who is intimately familiar with CSS and what is and isn't possible and an engineering team who have an appreciation of the importance of design and aesthetics.
In my freelance life (having had the benefit of working in both camps) I find it much easier to mock-up in photoshop first because I know what I can and can't do. And photoshop mockups are a lot easier to change on client feedback than are CSS and markup. Also, if you can show your client a mock-up, they feel more secure because they know that their money is going into a well planned project with a definate direction.
Hope this helps!
I currently do a lot of work in ActionScript 3.0, I also love to program in Java. Is JavaFX perfect for me? What is the general feeling on JavaFX, will it become a power house, or go down the same path as Java Applets? Could the designers I work with become comfortable with JavaFX to the same extent they are comfortable with ActionScript and JavaScript?
Just wanted to add my $.02... I've been working in JavaFX for the last 4 days on my first little side-project using it. As some background, I've been programming professionally for about 9 years, starting with C, and have been doing Java and C#/.NET for the last 6 yrs.
IMO, JavaFX its way more frustrating that it should be. Here are some gripes:
The syntax is just odd at times. It could easily be more like Java, since its JavaFX. But the syntax isn't an easy transition from Java.
The order of items in a .fx file actually matters, which means you run into stupid circular reference errors, and "oh you can't use this variable yet because it hasn't been initialized" problems that the compiler should handle with ease, but doesn't.
Random things just don't work. Actions/events on Swing controls don't always work, for example SwingSliderBar's onKeyPressed/released don't seem to be called.
Error handling is just bad. If an exception occurs that isn't handled, there is no real way to tell other than the Java console, and UI elements start to react funny. For example, make a SwingText box and bind its value to a variable. Now trying to edit the value in the text box will throw an exception because you cant edit the bound variable. However in the UI, the text box just starts having funny things happen. some characters only 1/2 paint, sometimes backspace does nothing, sometimes it deletes a character, sometimes you can press 2 keys ont eh keyboard like "1" and "2" and the text box will end up having "21" entered in it instead of "12", etc...
Although my absolute #1 problem with JavaFX development right now is Netbeans. It is pathetically bad at JFX. Can't debug, errors display wrong in the IDE (I've had it flag comments as errors!), the intellisence only works like 40% of the time, event he code templates preprogrammed in the IDE for drag & dropping controls aren't correct. I forget which one, but one of them drops a "&" at the end of the inserted code that is never valid and always has to be manually deleted... its just plain awful, and is unacceptable for a company like Sun.
Another gripe is general documentation. Its just lacking. Somehow the JavaFX API doesn't even come up as the #1 search result on google when searching for methods/classes. Tons of "examples" out on the web don't work any more as every version has major refactoring changes, and classes removed or renamed.
Overall, I give JFX a 4 out of 10. I want to like it, but JFX 1.1 just doesn't cut it... its definitely not what I would consider "production ready".
A resounding "meh".
When I looked at it a year ago, they had a one-way SVG to JavaFx conversion tool. Great, so you can author your visual content once, mark it up with a lot of behaviour, and then the next time you want to make it look good, then what?
If you take a look at this tutorial you can see what I mean. We're drawing stuff by dragging shapes from a palette into source code. OMGWTF. I am not showing that to my graphics department.
I hope I'm wrong about JavaFx, but I don't think they get it. Please, won't somebody at Sun give us a presentation layer that doesn't have its tentacles inextricably intertwined with code?
I left my last job to move from Java to .NET development.
There were a number of reasons for making the move, but the single biggest reason was that I was sick and tired of trying to build 1st class UI software with Java & Swing. It has been six years and I'm so glad I moved on. I see no reason to believe that Sun finally understands UI development with JavaFX.
I am convinced that Microsoft is finally in the process of giving us a platform to build rich interactive applications in the browser. I say that after having built commercially available software which was delivered as a Netscape Plugin 13 years ago, followed by ActiveX controls and Java Applets, and seeing all of these platforms fail to become ubiquitous in the enterprise for one reason or another.
I realize that Silverlight 2 is still lacking in depth and maturity, but Microsoft has shown me enough commitment at this point that I believe it will be the dominant RIA platform in a few short years - at least for projects which require a "real" programming language. I am sure Flash et al. is not going away anytime soon, but Flash is not appropriate for the kinds of software my company builds.
The icing on the cake for me is the fact that I will still be able to use Visual Studio, C# and a large percentage of my current code base (the core engine which is entirely separate from the UI). Of course, if you are coming from ActionScript, this would not help you.
One more important point is the fact that Silverlight and WPF share so much in common. Our plan is to share a large amount of implementation between Silverlight and WPF versions of our software. It is only a matter of time before WPF is the standard for Windows applications – I don’t know whether that is a couple of years or ten years, but it will clearly happen over time. Being able to target the most popular browsers / OS’s with Silverlight and Windows from the same code base is a tremendous advantage IMO.
If you know Java then moving to C# is a piece of cake. And unless you are using one of the nice (not free) Java IDEs, then even the free versions of Visual Studio will be an improvement over what you are used to. The hurdle will be learning the new way of doing things with XAML – but it’s some pretty cool stuff so you might actually enjoy it.
Although it appears fairly powerful in terms of capabilities, I'm kinda blah about JavaFX because of its structure and implementation. It seems like a really half-hearted attempt at getting into the Flash/Silverlight market. Too scripty.
I would argue in favor of going the Silverlight 2 route, but I'm primarily a C# developer so I'm a little biased there. If you don't like that route for whatever reason but still want a richer UX for your users, I'd suggest Flex; it seems much better organized than JavaFX to me.
Just my two cents on the subject.
If you know Java but want to do the stuff you thought was only feasible in Flash - then yes JavaFX would be good for you.
Without a doubt it's going to be much more easier to merge your Java knowledge with the design stuff.
And I believe the tooling will only get better which will make it simpler to use.
Unless you’re working on an internal app I would stay away from it. Users generally don’t want to have to deal with another program that accomplishes the same thing as Flash. I don’t think its install base is large enough yet to make it convenient for end users.
I've been developing Flash Applications with Flex for about 2 years now and I decided to give a try to JavaFX because we are constantly getting user complains that they cant use the applications from their IPhones (and I love Java).
That's one strike for Flash (no wide mobile support).
To be honest I was quite impressed with JavaFX (in a very bad way).
The documentation is incomplete.
The script is simply awful; its this weird hybrid between JSON and R with a feeling of a Java-deja-vu.
I spent the first 3 days painting polygons and making gradients with CODE... WTF!!
I tried to convince my graphic department to try it and they simply don't seam to grasp how the production suite is supposed to work, they keep complaining that Flex skinning is way easy and looks better in the end (Which is absolutely true).
The "CSS support" is simply a bad joke.
It generally feels like a mediocre attempt to offer an option for RIA frontend.
I can only think of a couple of good things about it:
It can be run from an IPhone / IPad and almost all mobile devices.
You have access to all the Java code you want which is great considering the limitations that ActionScript has (no overloading, no private constructors, etc). This is a great thing for us the programmers, but lets remember for a second that this is a frontend/presentation technology... that means that users will have to actually see the thing, so if it doesn't look good and have cool animations / effects they wont dig it.
The Script is way less verbose that MXML files are (with the cost of being unintelligible).
Talking about performance... Flash Player is this huge green blob that keeps growing and growing until no RAM is left compared to how JavaFX runs (JVM rocks! unfortunately this has nothing to do with the actual JavaFX API its just that the JVM... well it rocks!).
It has this cool feature where you can drag the applet outside the Web Browser.
In the end, Im happy I have an option to go mobile but this is light years way of the matureness that Flex/Flash has accomplished regarding RIA applications. The future of Flex/Flash as a wide distributed web technology is not clear (it may end up being used only for annoying banners and online games), no one wants to depend in a close technology as the Flash Player is, that's why the whole Web community is striving to get Flash out of the picture (HTML5 video support, No Flash Player for Apple devices, etc). So an attempt to have an open one is always welcomed, it's just that JavaFX feels like this incomplete rushed beta version of something that Sun felt obligated to come up with in a weekend during a bad hangover.
I Hope this is useful to someone (and offensive to someone at Sun/Oracle =p ).
I've spent the weekend 'playing with it. I see nothing useful in it. It's a iteration of swing / awt. I guess it will be nice for mobile devices but beyond that its nothing useful.
Ideally I'd like to use flash but find it painful to intergrate with a backend of any type.
Well, the syntax of both ActionScript and JavaFX seem to share a lot of similarities, so maybe "Yes".
I'm learning JavaFX script at the moment and I actually like it. But what I don't like, and is maybe it's biggest drawback, is it's awful documentation, which is often not up to date or incomplete.
I've been working on a JavaFX application for several months now. Personally, I love the language. They seemed to me to have made some very smart decisions in choosing the syntax and language constructs (I can bore you with a list if you'd like). I've been programming in it for a few months now and it seems like a very efficient and even enjoyable language to program in.
I think its best use right now is for desktop applications and/or applications deployed through webstart. On the desktop it has a rich set of features and can still make use of the other features of Swing and the rest of Java. From what I hear applets are still slow on some systems, and without Android support the mobile capabilities are non-features. The applet/mobile/TV/web support seems to me more like a bonus for desktop developers then as key features that would get you to use the technology.
So it really all depends on what you plan to use it for. If you are building desktop applications that you want to run on the Java VM that can make use of easy multimedia and rich ui controls, then I think there are good reasons to look at the language. WebStart has improved quite a bit and makes for a nice deployment tool. If you are looking to build web applications, then it might be interesting, but for now I'd say HTML5/ajax are more relevant (you might want to look at ZK in this case). However even with HTML5 ajax has its limitations, and if you find yourself running into them then JavaFX may offer you options. For mobile platforms it won't be relevant until there is stable Android support - in that case I'd just stick with the Android platform itself for now.