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!
Related
Our company is redesigning a web service as an SPA. I designed the rough version of frontend using jquery+css+html. but one of my features is the Tabs interface. It can have up to 8 tabs and it seemed to slow down the whole web app. Each tab contains a table with sth like 100+ rows with the exception of few tabs that has a bit more complex ui.
Now, we have this another company that's been assigned to complete the service with the backend modifications and apply the new ui. This company insists on using iframes to make it easier for multiple developers to work to together at the same time and also improve performance.
I honestly think this makes little sense especially considering the DOM structure is hardly complex nor long for each tab. But the truth is iframe is something i do not like for no apparent reason. So i was wondering if people can advise on why not to use it or even, why i should go along with it
This is a question that is still relevant, so I'll throw in an answer 4 years too late. SPA's can quickly become monolithic, especially for enterprise apps, with slow build times, poor developer experience, framework lock-in and increasing difficulty to coordinate frequent stable releases. This is a more-or-less acknowledged problem, to which the solution goes under the banner micro front ends.
Here's a thoughtful article on Martin Fowler, on micro front ends. You'll note that Iframes are the 2nd "best" solution for creating a shell for your micro front ends, despite the fact that no one wants to use them because they're old fashioned and not cool. They permit a good degree of isolation between frames (separate documents, separate scopes). They're simple and well understood. IFrames descend from framesets, released with Netscape 2 round 1996. Web purists were horrified, but they straight away permitted content panes to scroll independently of the navigation, giving us the left-hand navigation panel that's with us still. So there you have it, frames are a permanently unfashionable but robust and useful solution.
I think that this is a bad idea to use iframes for this purpose.
iframe is slow, and pass events and info between the main frame to the iframe is not so easy.
The answer for this is very simple, use web-components.
This is solution for multiple developers to work together at the same time.Each developer works on single or multiple web-component, and also make development faster when you can reuse and share components.
If you load the components and render them in the right time you can gain really good performance, better then iframe.
Now to your problem, you can do any tab as a component and only when the user move to this tab render it. Thus you dont have to render all the tabs but only one.
Take a look at polymer - a library that is a sugar syntax for web-component.
You can also look at the other frameworks angular,react...
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.
As a developer of a traditional ASP.NET web application (non-MVC) who is getting requests for a mobile-friendly version, I'm wondering where I might find some wisdom about the best way to approach the problem. We currently mask most of our database access through web service calls.
It seems like many shops would find themselves in this situation: We have limited resources and don't wish to create a maintenance headache by having versions of an application diverge greatly.
Is there a set of best practices for taking an existing System.Web application and reorganizing code in order to accommodate adding mobile-friendliness. The general approach I'm thinking of is:
Make small stylistic changes on the
client using CSS or even JavaScript.
Make any necessary changes in data,
workflow, or markup in server-side
code.
Keep as much code as possible common
to the two versions by organizing
non-UI logic into separate
assemblies. Conditional compilation
would be used in code-behind where
UIs must diverge.
What are the gotchas that I'll run into with this approach?
Short and sweet:
Read the W3C Mobile Web Application Best Practices
Separate your business/application logic and presentation logic as much as possible
Do server-side detection of mobile devices; serve an extremely simplified UI to mobile devices
Use client-side techniques like CSS media queries and feature detection (such as that done with Modernizr) to do progressive enhancement
The long version:
The most important thing to remember is that as similar as they appear, the mobile web and desktop web ARE different. The analogy I use the difference between a street and a sidewalk. Both of them are made for generally the same purpose - to get people from one location to another. However, they were designed separately and are intended for use by different modes of transport. You can drive a car on the sidewalk, and you can walk in the middle of the street, but neither experience will be optimal.
Long story short, for a good mobile site, you must design specifically for a mobile device. This doesn't mean you can't reuse logic - you definitely should. I'm just saying that using JavaScript/CSS to hide a few elements does not turn a regular site into a mobile site.
For what it's worth, I recently gave a presentation with one of my colleagues on mobile web development strategies. It is mostly targeted towards mobile web in higher education (college campuses) and my campus (UCSB), but many of the strategies and techniques are widely applicable. Interested parties can find the presentation and related resources here: https://it.ucsb.edu/groups/wsg/mobile-web-brown-bag
Resources
Server-Side Device Detection:
DeviceAtlas
WURFL
51Degrees.mobi
Client-Side Feature Support Detection / Progressive Enhancement:
Modernizr
EnhanceJS
Random Resources
Mobile Web Resources (My colleague's reading list)
W3C Mobile Web Application Best Practices
First, these days mobile doesn't necessarily mean doing the things that System.Web.Mobile come, but rather supporting the mobile use case and the limitations of mobile devices. Or, you want to strip down your app to be relevent to mobile users, and you want to do things like limit bandwidth required, browser plugins, heavy scripting and screen size required. But you actually don't need to go back to the bad old days of WAP and such.
From my reading the way forward seems to be to design for mobile first and then customise the layout using #media CSS to introduce more design/functionality concepts in more capable devices.
http://www.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/
http://www.slideshare.net/arborwebsolutions/practical-beyond-responsive-web-design
I have used Flex for about a year before deciding that I would rather develop Actionscript projects.
At the time, it seemed that the framework was too heavy for the kind of work I was dealing with, mainly small web applications , personal sites, portfolios this sort of thing. I also thought that Flex was like a odd hybrid , something targeting seasoned developers but at the same time , adding some function wizards that seemed to target beginners. It seemed overly complexed in some areas and way too basic in others.
On the other hand, the IDE was great , definitely no comparison with Flash CS IDE , so for me it made sense to stick to AS3 projects and use Flex , now FlashBuilder to write my code.
( I need to point out that I'm not a Flash designer, so working with Flash CS was never an option. )
It's been a while since I had a look at the Flex framework and I'm wondering about other Flex/Flash developers position on this issue.
Would you only consider Flex for enterprise level projects? What are the advantages of using one over the other? If you were a Flash developer and moved to Flex, what were your motivations? If you're creating both Flex & Actionscript projects , what are your choice criteria?
Edit:
Although I have received a great answer, I would have been interested to hear from Flex's users, what's your main practical motivation ( as opposed to philosophical :) ) for using Flex over pure Actionscript projects?
Preamble: my experience is primarily with AS3 projects built using a combination of the Flash IDE (FIDE) and Flash Builder 4 (FB4).
I generally prefer pure AS3 (PAS3) projects over Flex projects for the following reasons:
Size - Flex projects have a much larger minimum size than PAS3 projects. Not suitable for lightweight applications.
Performance - Flash is not known for its performance, and the layout computations required by a complex Flex application will hammer the end-user's machine. To them, things just end-up feeling slow, non-responsive, or "gunky". Unfortunately, this means that the applications where Flex might be most attractive (i.e. a very complex, adaptable, UI) are the exact places where it stumbles. In the end, you end up writing all this bizarre performance-enhancing optimization code that takes away most of the time you gained from using the built-in layout system.
Metaphor and Appearance - Flex aims to allow developers to provide end-users with a mature, flexible UI that has the same widgets and widget behaviors that they are used to from native applications. However, due to the performance problems echoed above, the UI never feels quite as nice or responsive as a native app. In addition, it's missing all of the OS-specific peculiarities that end-users are used to and will expect. I don't really understand the motivation to try to emulate native app development or behavior - you're never going to win that fight. Best to make something that stands by itself, which is what most native web applications are doing.
Flexibility - Dovetailing into the previous argument, Flash's main advantage is its ability to do things that traditional UI widget libraries can't do (at least not very easily). You can make some really, really novel UIs in Flash that just aren't practical to do in native apps without mucking about in OpenGL. Using Flex makes creating novel UI hard again (but it does make creating standard UI much easier, even if it is, in my opinion, sub-standard UI).
I'm curious if anyone has some good examples of Flex being used in any popular, public websites. Grooveshark is the only one that I know about (which is quite nice, but suffers from many of the problems I've outlined, especially on OS X where Flash performance is still poor).
However - it's a tradeoff. Always remember that your time is valuable. Your users might accept a slightly clunky, slightly confusing interface if it lets them do really cool things and that would mean that you could release it now as opposed to later. This brings is to the major downsides of PAS3 development:
Effort vs. Reward - You have to program all of your own UI. All of it. This can lead to some really, really bloated code where you have to define tons of event listeners for every button you want to create. I don't know how many times I've written various kinds of layout code specific to what I was working on. You can try to write your own abstract classes for these (which I have done), but at some point you're just going to end up re-implementing the Flex framework. Hardly worth your time.
Development - You can either use just Flash Builder 4, in which case you have to construct every graphical asset by hand in code (which takes forever), or you use the FIDE, in which case you can make lovely artwork but you're stuck with a stone-age code IDE and it takes forrrrrreeeeeeevvvvver to compile anything. Currently I use a hybrid setup where art generated in the FIDE is automatically imported into my FB4 project, but even that is not a perfect solution. They really need to be integrated better.
Another set of things to keep in mind: things that Flash sucks at.
Flash sucks at text. Do not try to re-implement a web browser inside Flash. Flash is actually quite good at displayed relatively small amounts of text that is unselectable (and, through the use of embedded fonts, is always pixel-perfect), but don't try to create large, expansive text documents inside your Flash project. First, performance will be terrible, and second, users will expect the text to behave the same way all other large text fields do in their native applications (most specifically, their web browser). Selecting text in Flash doesn't feel right because it doesn't feel how your OS does it.
Flash doesn't play nice with mouse and keyboard input - it constantly fights with the enclosing browser for focus. If your system needs either of those things, users need to click on it first. Don't fall into a trap where people will get confused because their inputs are going to the wrong place.
Flash is a performance hog - we've all heard this one, and it's not nearly as much of a problem as people like to think, but it does mean that you'll have to put a lot of thought into the performance of your system. Your UI should run at a stable 60FPS when being used and should not use much if any CPU when the user is not interacting with it. If your FPS dips below 60, then your UI will feel slow and gunky compared to native or HTML5 UI. Also make sure to watch for memory leaks.
In the end: user your head. Both approaches are just tools in your arsenal.
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