The E-Series phones are being made to compete with the BlackBerry line. I currently own a Nokia 6820 which is the text messaging phone with a fold-out keyboard. I absolutely love it. It seems they have improved on this design with an enhanced screen and BlackBerry mail support.
Microsoft's Outlook Web Client has had rich UI functionality for years, albeit only available for IE. AJAX is the new buzz acronym and is gaining momentum, however this technology in my mind is antiquated.
What we really need are simi-fat clients with all of the benefits of both browser applications and traditional fat (windows-type) client applications.
This simi-fat client paradigm can be accomplished now in.NET by hosting windows forms controls within IE. It is a pain to do currently, with all of the com-interop needed to talk to IE. Maybe this approach will gain momentum as the AJAX craze come to an end and browsers become increasingly smarter.
Lets see, first came the client/server applications and all was well! Well, not exactly first, but for the purpose of this discussion I'll say client/server came first. Companies grew faster than tech services could scale-out servers and management shouted "Oh no! This monolithic application will not scale!"
Then came the browser with all the promises of client side scripting and the developers shouted "I can do anything in a browser using sweet javascript code that you old client/server developers can do in a thick client! It will scale to tens of thousands!!"
2 years go by as developers embed thousands of lines of sweet javascript code to accomplish what you can do in a thick client in maybe 100 lines (I'm exaggerating here).
Management shouts "Oh no, my thin web application is taking 10 seconds to load as it parses 50K lines of sweet (now a spaghetti mess) javascript code!"
The new age of developer shouts "I can accomplish everything your antiquated web application can do, using XML web services while still providing a thin client with increased functionality in half the development time! Not to mention the application will be self updating so you will never need to support older versions of the application!"
I believe very strongly in a formal Requirements Analysis (RA) document that the end user will sign off on before any development begins. The RA document is a means for the developer to thoroughly document and understand the problem, and also for the client to understand what he/she will receive at project completion. The various projects I have worked on have had differing RA documents but they all have some boiler plate sections:
Purpose
Requirements
Definitions
Business Rules
Use Cases
Wire Frames (UI)
All of the terminology within the document is non-technical and basically describes the said business process and the proposed technical solution. In my experience the clients always flip to the wire frames section of the document, since this is the easiest thing for them to understand (pretty pictures!). A wire frame is really just a stencil of a screen created in any modeling tool.
So now you must be thinking why is he mixing design with definition work? I'm sure some would argue that the wire frame need not be in the RA document, since this is really design. However, a client may find it easier if they can walk thru the use case while looking at a screen representation.
Once client sign-off has been obtained that's when we get into the fun design stuff. Depending on the said tasks complexity you can utilize UML to further document the process. Any design documentation will be separate from the RA documentation but it will accompany the RA document when handing off to a developer. To me the single most important design document is the class diagram, and depending on complexity possibly a sequence diagram. I use UML on an as needed bases, you'll never need it all, but pick and choose different pieces as you see fit.
Transformers were among the coolest toys that I recall as a child. I can remember opening a new GO BOT and spending hours trying to figure out how to morph the figure into a plane, boom box, gun, etc. Quality made toys from what I remember, you just don't see this level of craftsmanship in any of the toys today.Transformers were among the coolest toys that I recall as a child. I can remember opening a new "GO BOT" and spending hour's trying to figure out how to morph the figure into a plane, boom box, gun, etc. These were quality toys from what I remember, which undoubtedly have stood the test of time; you just don't see this level of craftsmanship in any of the toys today, period.
Couldn't they make this thing look a little "cooler"? I mean, with the onslaught of portable media devices and the thousands of man hours spent trying to make the aesthetics on these devices as appealing as possible, why are Delphi's products waning in this area?
Slashdot Mirror
http://www.liveplasma.com/ (Flash application)
I believe this is the company that does the related stories matrix on news.com.com.
"Google Gmail and Google Maps are good examples of a very simple use of AJAX."
I would go out on a limb here and say that neither of these applications could be considered "simple" within any stretch of the word.
Who is this lady anyway?
The E-Series phones are being made to compete with the BlackBerry line. I currently own a Nokia 6820 which is the text messaging phone with a fold-out keyboard. I absolutely love it. It seems they have improved on this design with an enhanced screen and BlackBerry mail support.
Check out the E-Series line: http://www.engadget.com/entry/1234000193062973/
Microsoft's Outlook Web Client has had rich UI functionality for years, albeit only available for IE. AJAX is the new buzz acronym and is gaining momentum, however this technology in my mind is antiquated.
What we really need are simi-fat clients with all of the benefits of both browser applications and traditional fat (windows-type) client applications.
This simi-fat client paradigm can be accomplished now in .NET by hosting windows forms controls within IE. It is a pain to do currently, with all of the com-interop needed to talk to IE. Maybe this approach will gain momentum as the AJAX craze come to an end and browsers become increasingly smarter.
Lets see, first came the client/server applications and all was well! Well, not exactly first, but for the purpose of this discussion I'll say client/server came first. Companies grew faster than tech services could scale-out servers and management shouted "Oh no! This monolithic application will not scale!"
Then came the browser with all the promises of client side scripting and the developers shouted "I can do anything in a browser using sweet javascript code that you old client/server developers can do in a thick client! It will scale to tens of thousands!!"
2 years go by as developers embed thousands of lines of sweet javascript code to accomplish what you can do in a thick client in maybe 100 lines (I'm exaggerating here).
Management shouts "Oh no, my thin web application is taking 10 seconds to load as it parses 50K lines of sweet (now a spaghetti mess) javascript code!"
The new age of developer shouts "I can accomplish everything your antiquated web application can do, using XML web services while still providing a thin client with increased functionality in half the development time! Not to mention the application will be self updating so you will never need to support older versions of the application!"
And managment shouts "WTF!"
Purpose
Requirements
Definitions
Business Rules
Use Cases
Wire Frames (UI)
All of the terminology within the document is non-technical and basically describes the said business process and the proposed technical solution. In my experience the clients always flip to the wire frames section of the document, since this is the easiest thing for them to understand (pretty pictures!). A wire frame is really just a stencil of a screen created in any modeling tool.
So now you must be thinking why is he mixing design with definition work? I'm sure some would argue that the wire frame need not be in the RA document, since this is really design. However, a client may find it easier if they can walk thru the use case while looking at a screen representation.
Once client sign-off has been obtained that's when we get into the fun design stuff. Depending on the said tasks complexity you can utilize UML to further document the process. Any design documentation will be separate from the RA documentation but it will accompany the RA document when handing off to a developer. To me the single most important design document is the class diagram, and depending on complexity possibly a sequence diagram. I use UML on an as needed bases, you'll never need it all, but pick and choose different pieces as you see fit.
The 5 D's of software development:
Discover (Business Briefs)
Define (RA Document)
Design (UML)
Develop
Deploy
Transformers were among the coolest toys that I recall as a child. I can remember opening a new GO BOT and spending hours trying to figure out how to morph the figure into a plane, boom box, gun, etc. Quality made toys from what I remember, you just don't see this level of craftsmanship in any of the toys today.Transformers were among the coolest toys that I recall as a child. I can remember opening a new "GO BOT" and spending hour's trying to figure out how to morph the figure into a plane, boom box, gun, etc. These were quality toys from what I remember, which undoubtedly have stood the test of time; you just don't see this level of craftsmanship in any of the toys today, period.
Couldn't they make this thing look a little "cooler"? I mean, with the onslaught of portable media devices and the thousands of man hours spent trying to make the aesthetics on these devices as appealing as possible, why are Delphi's products waning in this area?