diff --git a/1_Desktop/03_Mockup/.preview_ch3_mockup.html b/1_Desktop/03_Mockup/.preview_ch3_mockup.html deleted file mode 100644 index 8c07e378..00000000 --- a/1_Desktop/03_Mockup/.preview_ch3_mockup.html +++ /dev/null @@ -1,15331 +0,0 @@ - - - - - - - - - - - -
-
-

Mocking Up the Application «Save a Child»

-
-

The time has come to start working on our Web application Save a Child -that will supports donations to ill children. In this chapter we’ll take -care of the Web design and will create the first prototype of the Save a -Child site.

-
-

Introducing Balsamic Mockups

-

First, we’ll create a mockup (a.k.a. wireframes) - a set of images -depicting various views of our Save a Child application. The images may -contain comments in the form of callouts that briefly explain what -should change in a view if a user will make a certain action, -e.g. clicks on the button. You can also think of a UI of any application -as a set of states and the user’s action result in your application’s -transition from one state to the other. As nerds and mathematicians say -“UI of your application is a -finite state machine”, -which at any given point of time is in one of the finite number of -states, for example, in the view state Donate Form.

-

Visualize yourself sitting in a cafeteria and drawing sketches of your -Web site on a napkin. Well, we’ll use an electronic napkin so to speak - -an excellent prototyping tool called Balsamic -Mockups. This is an easy to use program. It gives you a working area -where you create a mockup of your future Web application by dragging and -dropping the required UI components from the toolbar onto the image of -the Web page (see Figure 3-1).

-

-image -

-

Figure 3-1. The working area of Balsamiq Mockups

-

When the prototype is done, it can be saved as an image and sent to the -project owner. Another option is to export the Balsamiq project into -XML, and if both the project owner and Web designer have Balsamiq -installed, the can work on it in collaboration. For example, the -designer exports the current states of the project, the owner imports it -and makes corrections or comments, then exports it again and sends it -back to the designer.

-
-
-

The Project Owner Talks to a Web Designer

-

At this stage a Web designer talks to the project owner discussing the -required functionality and then creates the UI to be implemented by Web -developers. The artifacts given to developers by the designer vary -depending by the qualifications of the designer. This can be a set of -images representing different states of the UI with little callouts -explaining the navigation of the application. If the Web designer is -familiar with HTML and CSS, you may get a working prototype in the form -of HTML and CSS files, and this is exactly what we’ll create by the end -of this chapter.

-

This is what the project owner said to our designer, The Save a Child -Web site should allow people to make donations to the ill children. The -users should be able to find these children by selecting an area on the -map. The site should be integrated with a payment system, include a -video player and display statistics about the donors and recepients. The -site should include a simple chat room and have a simple integration -with Twitter and Facebook. The mockup should include three versions of -the UI supporting desktops, tablets, and smartphones.''* This is what -the project owner said to our designer,

-
-
-

The Save a Child Web site -should allow people to make donations to the ill children. The users -should be able to find these children by selecting an area on the map. -The site should be integrated with a payment system, include a video -player and display statistics about the donors and recipients. The site -should include a simple chat room and have a simple integration with -Twitter and Facebook. The mockup should include three versions of the UI -supporting desktops, tablets, and smartphones.

-
-
-
-

The Web designer opened Balsamiq and started to work. She decided that -the main window will consist of four areas laid out vertically: 1. A -header with the logo and several navigation buttons 2. The main area -with the Donate support plus the video player 3. The area with the Find -Local Kid, statistics, and a chat room. 4. A footer with several -house-holding links plus the icons for Twitter and FaceBook.

-
-
-

The First Mockups

-

The first deliverable of our Web designer depicted two states of the UI: -before and after clicking the button Donate Now. The Web designer -suggested that on the button click the Video Player would turn into a -small button revealing the donation form.

-

-image -

-

Figure 3-2. The main view before clicking Donate Now. Take 1.

-

-image -

-

Figure 3-3. The main view after clicking Donate Now. Take 1.

-

The project owner suggested that turning the video into a button may not -be a the best solution. We shouldn’t forget that the main goal of this -application is collecting donation, so they decided to move the video -player to the lower portion of the window. The next version of the -mockup looks as shown in Figure 3-4 and 3-5. The latter shows different -UI states should the user decide to log in.

-

Figure 3-4. The main view. Take 2.

-

Next comes authorization. The view states in this process are: 1. Not -Logged On 2. The Login Form 3. Wrong ID/Password 4. Forgot Password 5. -Successfully Logged On

-

The Web designer has to create a mockup for each of these states. The -project owner will review them and can return them back with some -comments. Figure 3-5 illustrates selected views from authorization. Due -to some miscommunication the Web designer assumed that unless the user -log on to the application, she won’t be able to see Save a Child. This -is clearly wrong as the process of making donations has to be as easy as -possible, and forcing the donor to log on may result in abandoning Save -a Child application by some people.

-

-image - Figure 3-5. Selected authorization UI states

-
-
-

From the Mockup to HTML Prototype

-

We are lucky - our Web designer knows HTML and CSS. In this section -we’ll turn the still mockups into the first HTML prototype, which will -use only hard-coded data but the layout of the site will be done in CSS -and we’ll use HTML5 markup.

-
-
-

“In this book we assume that the users of our Save a Child site work -with the latest versions of Web Browsers FireFox, Safari, Google Chrome -and Internet Explorer. While in the real world Web developers need to -deal with finding workarounds to the unsupported CSS or HTML5 features -in the old browsers, the modern IDE generate HTML5 boilerplate code that -include large CSS files providing different solutions to older -browsers.”

-
-
-
-
-
-

Adding Styles With CSS

-

We’ve been using some CSS in short code samples from Chapter 2, and now -let’s apply styles to make Save a Child look as in the mockup.We’ve been -using some CSS in short code samples from Chapter 2, and now let’s apply -styles to make Save a Child look as in the mockup.

-
-
-
-
-

- - - diff --git a/1_Desktop/08_Websockets/.preview_Chapter_8_Replacing_HTTP_With_WebSockets.html b/1_Desktop/08_Websockets/.preview_Chapter_8_Replacing_HTTP_With_WebSockets.html deleted file mode 100644 index 1d24d210..00000000 --- a/1_Desktop/08_Websockets/.preview_Chapter_8_Replacing_HTTP_With_WebSockets.html +++ /dev/null @@ -1,1255 +0,0 @@ - - - - - - - - - - - -
-
-

Replacing HTTP with WebSockets

-
-
-
-

Reducing kilobytes of data to 2 bytes… and reducing latency from 150ms -to 50 ms is far more than marginal. In fact, these two factors alone are -enough to make WebSocket seriously interesting…

-
-
-— http://ietf.org/mail-archive/web/hybi/current/msg00784.html -
-

This chapter will introduce the WebSocket API, which is a part of HTML5 spec. We’ll pick one of the data flow in Save a Child site and replace HTTP communication with WebSockets protocol. Using the monitoring tool we’ll show the performance bandwidth usage benefits that WebSockets protocol brings to the Web. -This chapter will be based on this WebSockets presentation.

- -

Show the server-side data push with Websockets. Look at Socket.IO library. Compary the data throughput with the HTTP datapush demonstrated in Ch4.

-
-

Legacy Web and its options for «Realtime» apps

-
    -
  • -

    -(Short) Polling -

    -
      -
    • -

      -send request to the server every X seconds. -

      -
    • -
    • -

      -the response is «empty» if there is no update -

      -
    • -
    -
  • -
  • -

    -Long Polling (ajax push) -

    -
      -
    • -

      -send request to the server, wait for an event to happen, then send the response -

      -
    • -
    • -

      -the response is never empty -

      -
    • -
    • -

      -HTTP specification satisfied: indistinguishable from «slow» server -

      -
    • -
    -
  • -
  • -

    -HTTP Streaming -

    -
      -
    • -

      -send the request, wait for events, stream multipart/chunked response, and then wait for the events. -

      -
    • -
    • -

      -The response is continually appended to. -

      -
    • -
    -
  • -
-

TBD

-
-
-

Server-Sent Events

-
    -
  • -

    -eventSource API -

    -
  • -
  • -

    -Use only when data doesn’t need to be sent from the client to the server -

    -
  • -
  • -

    -Standardization of server-side push -

    -
  • -
  • -

    -Minimal overhead (tens of bytes, not hundreds) -

    -
  • -
  • -

    -HTTP based (but requires server support) -

    -
  • -
-
-
-
var dataStream = new EventSource("http://www.example.com"); // 1
-
-dataStream.onopen = function(evt) {         // 2
-    console.log("open");
-}
-dataStream.onerror = function(evt) {
-    console.log("error");
-};
-
-dataStream.onmessage = function(evt) {      // 3
-    // Process message
-    console.log("message: " + evt.data);
-}
-
- - - -
1 -Create new EventSource -
2 -Add handlers for open and error -
3 -Handle messages -
-
-
-

Introducing Websockets

-

What is websockets?

-
-
-

Clean standardization for complex hacks used to simulate real time, bidirectional communication

-
-
-— http://peterlubbers.github.com/devcon5-keynote/#38 -
-
    -
  • -

    -IETF RFC 6455 Protocol -

    -
  • -
  • -

    -Client-side W3C API -

    -
      -
    • -

      -Websocket Interface -

      -
    • -
    -
  • -
-
-
-
[Constructor(DOMString url, optional (DOMString or DOMString[]) protocols)]
-interface WebSocket : EventTarget {
-  readonly attribute DOMString url;
-
-  // ready state
-  const unsigned short CONNECTING = 0;
-  const unsigned short OPEN = 1;
-  const unsigned short CLOSING = 2;
-  const unsigned short CLOSED = 3;
-  readonly attribute unsigned short readyState;
-  readonly attribute unsigned long bufferedAmount;
-
-  // networking
-  [TreatNonCallableAsNull] attribute Function? onopen;
-  [TreatNonCallableAsNull] attribute Function? onerror;
-  [TreatNonCallableAsNull] attribute Function? onclose;
-  readonly attribute DOMString extensions;
-  readonly attribute DOMString protocol;
-  void close([Clamp] optional unsigned short code, optional DOMString reason);
-
-  // messaging
-  [TreatNonCallableAsNull] attribute Function? onmessage;
-           attribute DOMString binaryType;
-  void send(DOMString data);
-  void send(ArrayBufferView data);
-  void send(Blob data);
-};
-
    -
  • -

    -API -

    -
  • -
-
-
-
var ws;
-if(window.WebSocket) {   
-    output("WebSocket supported in your browser");   
-
-    ws = new WebSocket("ws://www.websockets.org/echo");
-
-    // Set event handlers.
-    ws.onopen = function() { output("onopen"); 
-    };   
-
-    ws.onmessage = function(e) {     
-        // e.data contains received string.
-             output("echo from server : " + e.data);
-    };
-
-    ws.onclose = function() {
-        output("onclose"); 
-    };
-    ws.onerror = function() { output("onerror"); 
-    };
-
-} else {
-    output("WebSocket not supported in your browser");
-}
-
    -
  • -

    -websocket handshake -

    -
      -
    1. -

      -client sends GET-request for protocol upgradein -

      -
    2. -
    3. -

      -server send response and confirms protocol upgrade -

      -
    4. -
    5. -

      -websocket.readyState==1 -

      -
    6. -
    7. -

      -websocket.onmessage listener for incoming messages, websocket.send() to send data to server -

      -
    8. -
    -
  • -
-
-
-
- - - -
-Note -There is no limit to the number of established WebSocket connections a client can have with a single remote host. Servers can refuse to accept connections from hosts/IP addresses with an excessive number of existing connections or disconnect resource- hogging connections when suffering high load.
-
-
-
    -
  • -

    -websocket frame anatomy -

    -
  • -
  • -

    -heartbeating -

    -
  • -
  • -

    -Client-side frameworks -

    -
  • -
  • -

    -Server-side API -

    -
  • -
-
-
-

Websocket Use Cases

-

WebSockets really shine with following applications:

-
    -
  • -

    -Live trading/sports ticker -

    -
  • -
  • -

    -Controlling medical equipment over the web -

    -
  • -
  • -

    -Chat applications -

    -
  • -
  • -

    -Multiplayer online games -

    -
  • -
  • -

    -Realtime updating social streams -

    -
  • -
-

Downside: websocket spec gives you only transport, but there is no highlevel protocol. Developers need to invent problem related protocols (text or binary).

-
-

Protocols thoughts (for Enterprise world)

-
-
-
-
-

Websockets and proxies

-

TBD

-
-
-

WebSockets and HTTP 2.0

-
-
-

"I use the metaphor of hammers and screwdrivers. Both tools are indispensible in my workshop…

-

Use the right tool for the job. -In the case of page and object delivery use SPDY. -In the case of lightweight or streaming data delivery look to WebSocket."

- -
-
-Stephen Ludin
-— Chief Product Architect at Akamai -
-
    -
  • -

    -http 2.0 and spdy -

    -
  • -
  • -

    -spdy and websockets -

    -
  • -
  • -

    -framed protocols (describe frames) -

    -
  • -
-
-
-
-
-

- - -