User Tools

Site Tools

Differences

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

Link to this comparison view

Next revision		Previous revision
mission:log:2015:04:06:howto-hacking-seamless-svg-background-tiles [2015/04/06 11:02] – created chronomission:log:2015:04:06:howto-hacking-seamless-svg-background-tiles [2015/09/08 21:00] (current) – [Basic PoC Demonstrator] chrono
Line 2: Line 2:
  
 Image creation/manipulation is an essential part of UI design and, with Photoshop gone, GIMP and Inkscape came to the rescue. Almost all graphics used in the Apollo-NG realm are created with Inkscape. With many people already using Inkscape and it being a vector oriented tool creating SVGs, it was just a matter of time until the [[http://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG|SVG standard]] and its implementations matured and spread. Some features, such as SMIL animation and SVG Fonts are not as widely supported. There are many SVG authoring tools, and export to SVG is supported by all major vector graphics authoring tools. Image creation/manipulation is an essential part of UI design and, with Photoshop gone, GIMP and Inkscape came to the rescue. Almost all graphics used in the Apollo-NG realm are created with Inkscape. With many people already using Inkscape and it being a vector oriented tool creating SVGs, it was just a matter of time until the [[http://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG|SVG standard]] and its implementations matured and spread. Some features, such as SMIL animation and SVG Fonts are not as widely supported. There are many SVG authoring tools, and export to SVG is supported by all major vector graphics authoring tools.
 +
 +{{ :mission:log:2015:04:06:svg-seamless-background-hacking.jpg |}}
  
 SVG 2 is currently under development, and will add new ease-of-use features to SVG, as well as more closely integrating with HTML, CSS, and the DOM, and deprecating features not supported by all browsers. The SVG Working Group is currently working in parallel on a set of modules for extending prior specifications and adding functionality to CSS, and the new SVG 2 specification will combine those modules with the rest of the SVG framework to work across the full range of devices and platforms. SVG 2 is currently under development, and will add new ease-of-use features to SVG, as well as more closely integrating with HTML, CSS, and the DOM, and deprecating features not supported by all browsers. The SVG Working Group is currently working in parallel on a set of modules for extending prior specifications and adding functionality to CSS, and the new SVG 2 specification will combine those modules with the rest of the SVG framework to work across the full range of devices and platforms.
Line 121: 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 228: 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 changes, it's time to go ahead and try a less eye-cancer prone color combination:
    
 === SVG === === SVG ===
Line 342: 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 to be able to inject and alter any kind of UI element by backend or javascript, thus bringing development and design closer together, which seems similar to a DevOps role. There are still a couple of rules about design a developer-designer would have to learn and in the end nothing beats experience and practice. 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? Since we know now how to change the image by hand, we can teach a computer to do that :)+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 :)
  
 ===== Conclusion ===== ===== Conclusion =====
Line 357: 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:
Trace:

Page Tools