User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
mission:log:2015:04:06:howto-hacking-seamless-svg-background-tiles [2015/04/06 11:43]
chrono [Customize to suit color-space/identity]
mission:log:2015:04:06:howto-hacking-seamless-svg-background-tiles [2015/09/08 21:00] (current)
chrono [Basic PoC Demonstrator]
Line 123: Line 123:
 </code> </code>
  
-Sweet. More that 50% reduction in this case. This can be easily automated or abstracted/shortened with an alias in your shell's configuration.+Sweet. More than 50% reduction in this case. This can be easily automated or abstracted/shortened with an alias in your shell's configuration.
  
 === HTML/CSS Integration === === HTML/CSS Integration ===
Line 230: Line 230:
 ==== Customize to suit color-space/identity ==== ==== Customize to suit color-space/identity ====
  
-After we've established that the principle is working and we can easily make changes to it we can start to choose a less eye-cancer prone color combination:+After we've established that the principle is working and we can easily make changesit's time to go ahead and try a less eye-cancer prone color combination:
    
 === SVG === === SVG ===
Line 344: Line 344:
 Perfect. From a users perspective it seems way more easy to change a couple of numbers in a text file (or even use variables for them) than to learn some counter-intuitive click path, walking through endless menus to make a small change, similar to the ease of OpenSCAD vs. old-school CAD breeds.  Perfect. From a users perspective it seems way more easy to change a couple of numbers in a text file (or even use variables for them) than to learn some counter-intuitive click path, walking through endless menus to make a small change, similar to the ease of OpenSCAD vs. old-school CAD breeds. 
  
-But the real benefit is the prospect of SDUI, to be able to cheaply create, inject and alter any kind of UI "design" element on-the-fly by backend or javascript code, thus bringing development and design closer together, which seems similar to a DevOps role to implement and teach software defined infrastructure. Of course there are still a couple of rules about design a developer-designer would have to learn combined with some practice to gain experience. However, the process and necessary things to learn can be broken down and adapted much faster now to pave the way. How will we call this role in the future? DevIgn? +But the real benefit is the prospect of SDUI, to be able to cheaply create, inject and alter any kind of UI "design" element on-the-fly by backend or javascript code, thus bringing development and design closer together, which seems similar to a DevOps role to implement and teach software defined infrastructure. Of course there are still a couple of rules about design a developer-designer would have to learn combined with some practice to gain experience. However, the process and necessary things to learn can be broken down and adapted much faster. How will we call this role in the future? DevIgn? 
  
 Since we know now how to change the image by hand, we can simply teach a computer to do that :) Since we know now how to change the image by hand, we can simply teach a computer to do that :)
Line 361: Line 361:
 Let's say a website with 10 PNG UI elements is opened, the browser will get the html (request 1), interpret the html, load the stylesheet (request 2) and then go fetch the other assets (request 3-12) one by one. But each webserver has only a limited number of requests it can handle simultaneously. Let's say a website with 10 PNG UI elements is opened, the browser will get the html (request 1), interpret the html, load the stylesheet (request 2) and then go fetch the other assets (request 3-12) one by one. But each webserver has only a limited number of requests it can handle simultaneously.
  
-When you could put your assets directly into the stylesheet, each connection would only perform 2 instead of 12 requests. As a result, the webserver will be able to handle more than twice as many visitors before maxing out.+When you could put your assets directly into the stylesheet, each connection would only perform 2 instead of 12 requests. As a result, the same webserver will be able to handle more than twice as many visitors before maxing out.
  
-Additionally, more requests need more CPU, RAM, IO and therefore consume more power, not to mention the required bandwidth and power consumed in-transit by routers etc. This also applies to power constrained mobile devices like tables or smartphones where battery-runtime is everything. +Additionally, more requests need more CPU, RAM, IO and therefore consume more power, not to mention the required bandwidth and power consumed in-transit by routers etc. This also applies to power constrained mobile devices like tablets or smartphones where battery-runtime is everything. 
  
 In short, minding these issues will help with: In short, minding these issues will help with: