KoolSpan to seek $10M to $12M in VC this year

Bethesda-based mobile security company KoolSpan Inc. plans to seek between $10 million and $12 million in venture funding this year as it expands its international presence.

Company Senior Vice President Francis Knott said funding will be used to grow KoolSpan’s sales and engineering teams, particularly overseas.

“A lot of our growth is international. I would guess that for 2014, international will outweigh domestic as far as growth for us,” Knott said. “Foreign entities seem to be more embracing of pre-empting the problem that exists.”

Koolspan has about 40 employees, 30 of which are based in Maryland. Knott said the company plans to hire another 25 this year.

The company — who’s products include a TrustChip that slides into smartphones and other devices to secure their information — has offices in the United Kingdom, Italy and South Korea. It is also in the final stages of opening an office in the Middle East. Knott would not say where that office is, citing the volatility of the region.

The company also plans to open an office in Brazil this year.

KoolSpan has landed about $40 million in venture capital since its founding in 2003, said Knott, who would not reveal the company’s revenue or say whether it is profitable. Investors include New York-based Security Growth Partners and TWJ Capital in Bethesda.

KoolSpan’s customers include AT&T Wireless and Samsung. Knott said its competitors include Secusmart gmbH in Germany and Cellcrypt in Virginia.

Lawrence Livermore explores the shape of data, expanding query-free analytics

• By William Jackson
• Jan 09, 2014

Lawrence Livermore National Laboratory is taking advantage of federally funded research into topological data analysis (TDA) to find new ways of extracting and using information from data sets that are too large and complex to yield to traditional analytical techniques.

The lab is collaborating with Ayasdi Inc., a commercial spin-off from research at Stanford University that is funded through the Defense Advanced Research Projects Agency and the National Science Foundation.  Ayasdi’s Insight Discovery platform is a software suite already being used by private- and public-sector organizations, including the intelligence community, to glean insights from large and varied data collections.

“Big data challenges are a part of our mission,” said Anantha Krishnan,

director of the lab’s Office of Mission Innovation.

The lab uses high-performance computing for modeling and simulation in areas of energy, climate change, biological defense and national security. “For many years the lab has had to rely on homegrown technology,” Krishnan said. “We have developed our own set of data analysis tools and modeling and simulation tools.”

But the lab also is looking at commercial tools that have emerged as big data has become a mainstream subject in IT. “Our sense is that topological data analysis could be a big contributor to the things we do,” Krishnan said.

Topology is a branch of mathematics dating to the 18th century that studies shapes. In the 21st century it has been expanded to apply to problems beyond physical shapes and surfaces to include the very large and high-dimensional data sets that constitute what is called big data. Data has shape, and shape has meaning, said Krishnan. The lab’s work with Ayasdi, announced in November, is an effort to extract that meaning.

“We are going through the evaluation phase now,” said Krishnan. “Our hope is that in the next few months the value will become clear.” The challenge in working with big data is not just volume. Big data is more than small data made large, said Ben Mann, Ayasdi’s vice president of federal operations. “Big data, done right, is completely different.”

Read more at http://gcn.com/articles/2014/01/09/topographical-data-analysis.aspx

HTML is the language the web is built in, and it’s kind of a strange beast. Although it was originally intended as a way to easily share academic information across the Internet, it has been slowly transformed to accommodate the media-rich environment we know and love, sort of like a cherished lawn mower that has been fitted with jet engines.

Because of the haphazard nature of HTML (and JavaScript, the programming language that manipulates elements in HTML and makes them interactive), sometimes we have to think outside the box a bit. In this tutorial series, I will show you how to do cross-browser animation using a method called spriting, using only JavaScript and HTML (and a bit of CSS too). And, because this is a learning opportunity (and I am stubborn and like to do things the hard way), we will be doing it all without any external libraries (like jQuery).

This will be a four-part series. I’ll explain the spriting itself in part one (this article) with some basic JavaScript, but then in later installments we will move into some intermediate techniques like encapsulation, event handling, and touch screen support.

So let’s get started!

What Is Animation?

Animation is based on a phenomenon called persistence of vision, which basically says that if your brain sees lots of similar still images fast enough, then it will appear as though it is one moving image. Every kind of film or video uses this basic technique—many slightly different frames are shown in quick succession to make something appear to be moving. Film typically runs at 24 frames per second (₁), while broadcast television in North America is shown at 29.97 frames per second (₂). So, in other words, what we want to do is create something that shows similar frames really quickly (several times a second).

The Difficulties on the Web

There are two main reasons animation is difficult to use on the web:

1. The first is that different web browsers have different ways of interpreting HTML and JavaScript, so what works on one device often doesn’t work on another. Flash works great on most browsers, but support is starting to drop for it and iOS devices won’t allow it at all. Canvas has a lot of potential, but Internet Explorer 8 doesn’t support it. Same goes with Adobe Edge Animate. GIFs work on everything, but you can’t control the animation or make it interactive.
2. And for the second, every time an image is served on a web page, a separate request is made between the browser and server. These requests can add up, even over a lightning fast Internet connection, making having several frames each second unmanageable.

The Solution: Spriting

One way around these problems is to make a sprite sheet. In elements like divs, we can set a background image for the div that may be larger than the element itself. We can also set the background position so that we determine exactly which part of the larger image will show. A sprite sheet is a larger image made of several smaller images that we can move around so that it could take the place of many small images. Take a look at the example below, using J, the mascot of my company Joust Multimedia:

Although there are ten different images of J, they are placed together on one larger PNG file (we are using PNGs because they can show transparency). If we have a div that is only the size of one of the images, and we set this PNG as the background, it will look like a single image.

See the hazdm on CodePen.

Although this seems like a lot of trouble to go through to show an image, this method nicely fixes the two issues we had before. With very little JavaScript (one line!) you can change the background position of a div, and it works on everything. Also, since all of these frames are on the same image, it will only take one request to load that image in the page. So, once the page loads, it can switch between sprites with no problem at all.

So how do we set this up to animate easily then? The first step is to create the sprite sheet. You will want to know what the final dimensions of your image should be, and space the sprites accordingly in a grid. For instance, my J image is going to be 40px wide by 50px tall, so I lined up my sprites exactly 40px apart horizontally and exactly 50px apart vertically. It will probably be easiest if you set your starting sprite in the upper left corner.

Then we will set up a div with a bit of CSS to make sure that everything appears properly:

<div id="stage">
    	<div id="j" class="character"></div>
    </div>
    

And here is our CSS to make sure the sprite is showing correctly:

.character {
    	/*
    	 * Very important that we set the height and width of 
    	 * our characters to the height and width of the sprites
    	 */
    	height:50px;
    	width:40px;
    	/*
    	 * We need to position them absolutely so we can have full  
    	 * control over their position within the stage
    	 */
    	position:absolute;
    	left:100px;
    	top:120px;
    }
    
    #j {
    	/*
    	 * And now we set the background image for the character div 
    	 * to be the first sprite (in the upper left corner)
    	 */
    	background-image: url('j.png');
    	background-repeat:no-repeat;
    	background-position:0 0;
    }
    

Notice the following things:

• We specify the width and height of the div to the size of our sprite
• We specify the background-repeat to 'no-repeat'
• We specify the background-position to '0 0'—this will show the sprite in the top left corner

Now, it will just take a single line of JavaScript to change the background position to show the next sprite.

document.getElementById('j').style.backgroundPosition = '-40px 0px';
    

Here, we are selecting the element (with id='j'), and setting the style attribute 'backgroundPosition'. Notice that it is spelled 'backgroundPosition' in JavaScript, and not like 'background-position' in CSS. Also notice that in JavaScript, the 'px' is required for both the x and y amount—we cannot just pass it numbers. And because we are moving the background image, we have to move it in the opposite direction from what you might expect. To move to the sprite on the right, we have to have the image move 40px to the left.

Now, if we just have something simple to execute this code (like a button), we can see the frames changing in action: checkout the DIsgk on Codepen.

Additionally, you might be interested in taking a look at the source code for this page as well. It has all of the examples here with thorough comments. And here’s the sprite sheet I am using.

Next Up

What we’ve covered in this tutorial is a good start, but it isn’t really a proper animation. In part two of this series we will actually animate some running and jumping, by creating loops with the different sprites.

By part four, we will be creating mouseovers for a bit of robot action. See the ByGtv Codepen for a preview.

Conclusions & Drawbacks

Although this can be a great method for animating on the web, there are a few drawbacks. First, it can require you to create each individual frame of animation, which can be time-consuming. Second, browsers don’t have the most accurate of timers for animation, so if it is critical for your animation to be timed perfectly, then this may not work. Finally, mobile Safari (used on iPhones and iPads) has a “feature” where if you have a background image that is either larger than 2MB or larger than 1024 x 1024 x 3 pixels (or 3,145,728 total pixels), it will automatically rescale the image, ruining the spriting effect. This means that really large sprites, or animations with a very large number of sprites, are out of the question. But, for simple, small animations that you want to be very interactive, this is an easy and great way to get something that works everywhere.

Interesting Side Notes

1. Before sound was introduced with film, there wasn’t really a standard frame rate. The cameras were operated by a hand crank, so if you had a rookie cameraman the frame rate might slow down and speed up unintentionally. Similarly, less reputable theaters were notorious for telling their projectionists to crank the projector quicker to speed up the show so they could fit in more screenings. This is also why we stereotypically think of pre-sound movies as moving around comically fast—most were filmed around 16 to 18 fps, so when we play them today at 24 frames per second, they are moving faster than they were originally intended.

2. Television was originally broadcast at 30 fps in North America, but color television caused a glitch when shown at that speed. Engineers figured out that they could fix it by slowing down the frame rate by 0.1%, which is why it is now set at 29.97 fps. Also, besides all of the wacky technical issues involved with converting a film in 24 fps to display on television at 29.97 fps, showing television at a faster fps has had an interesting effect on the public. Many people watching the test screenings of “The Hobbit” at 48 fps reported that the increased frame rate made the film look “cheaper”, even though it was much higher quality than a typical film, just because they had grown to associate faster frame rates with watching something on television.

PSD to HTML tutorials are all over the web. In fact, many people have asked me why there’s not a PSD to HTML tutorial on Treehouse. In addition to the tutorials, there are lots of companies that will accept a PSD and convert it to a webpage for roughly $100 USD.

Google returns more than 48 million results for a “psd to html” search. It’s popular, but not the best way to make websites.

If it’s so popular, then how can I say that it’s dead? Well… I wish every web design quandary could fit into a poetic 140 character tweet, but this is a fuzzy issue that demands a more articulate explanation. Let’s dig in.

What is PSD to HTML?

In general, “PSD to HTML” is a workflow. First, a web page is designed in a Photoshop Document (PSD) and then converted to code (using HTML, CSS, and JavaScript). You could swap Photoshop with any other image editor (like Pixelmator, GIMP, and so on), but the principle is the same. Here’s a slightly more detailed step-by-step breakdown:

1. Design a high fidelity pixel-perfect mockup in Photoshop of exactly what you want your site to look like.
   
2. Use the slice tool to divide your website’s imagery and then export it for the web.
3. Write HTML and CSS that utilizes the imagery you exported from Photoshop.

At first glance, this might seem like a good idea. It can be difficult to start coding if you don’t know what the final result is going to look like, so experimenting in Photoshop first and then “exporting” it to HTML sounds like a granular and sensible process.

In Photoshop, the slices feature in the save for web dialog used to be an essential tool for designers saving assets from a PSD. It made it easy to “slice” a design into images and then layout in a web page using HTML and CSS.

Taking this idea further, many web companies have used PSD to HTML as a template for team workflows. In other words, a designer creates the Photoshop mockup and then hands it over to a developer that writes all of the code. In modern times, the job role of a web designer tends to encompass aesthetics as well as HTML and CSS coding.

Was PSD to HTML ever a good idea?

Yes, PSD to HTML workflows used to be one of the best ways to make websites. There’s two big reasons why PSD to HTML used to make sense.

The first reason is for image assets. Before browsers supported all the wonderful features of modern CSS (drop shadows, rounded corners, gradients, and more) it was very difficult to create cross-browser effects without the use of images. Designers would create shadows and rounded corners as images, then clever coding tricks were used to place the imagery on the page. These assets would need to be realized no matter what, so creating them at the same time as the high fidelity mockup actually saved time.

Prior to the development and widespread adoption of CSS, many websites were a collection of image assets that looked something like this. One of the most innovative techniques of the time was the sliding doors technique to create tabs back in 2003.

Secondly (and perhaps more importantly) the web used to only be available on desktop browsers and wasn’t really present on phones and tablets in the way it is today. Designing for one fixed resolution of 1024×768 used to be totally viable.

For these two reasons, it’s understandable why a designer would look to Photoshop as their primary web design tool. Image assets were needed for a single screen resolution.

What’s wrong with PSD to HTML now?

When pitted against other areas of art and technology, the web is a relatively young medium and things change fast. I’ve made dozens of websites using some variation of the PSD to HTML mindset and I’m sure many people reading this have done the same, but it’s time to move on. Here are the primary reasons why I believe thinking in terms of PSD to HTML is dead.

Responsive Web Design

First, there are now a myriad of methods for browsing the web. Phones, tablets, desktops, notebooks, televisions, and more. There is no single screen resolution that a designer can target. Taking that idea a few steps further, there’s really no number of screen resolutions that you can safely “target” anymore.

Screensiz.es provides tables of information about popular hardware devices.

I’m not going to delve into the finer details of responsive web design or scalable design, but the point is that Photoshop is pixel based. Web pages are fluid and change.

CSS Design

Second, new features in CSS have now become commonly available. There are still a few lingering issues here and there, but support has vastly improved in the last several years. Common effects like shadows, gradients, and rounded corners can be accomplished in CSS and usually don’t even need an image-based fallback anymore.

Maturity

Third, the web industry has grown up a lot. Collectively we’ve had more time to refine our present understanding of what works and what doesn’t. Most companies will expect a designer to take ownership of aesthetics as well as HTML and CSS code.

This also means there are much better tools to support modern workflows. CSS frameworks like Bootstrap and Foundation make it more viable to design in the browser. Apps like Balsamiq and Omnigraffle help to wireframe sites rapidly. Pencil and paper mockups have stood the test of time because they allow for extremely rapid iteration.

Does this mean Photoshop is dead?

No! Not even close. Photoshop is still very important to web design. The problem comes in when a powerful tool like Photoshop is used as a catch all solution without thinking of the higher level task (designing websites). Photoshop is awesome for editing and exporting photographs for web usage. There’s also plenty of situations where it still might make sense to generate full detail mockups (in Photoshop, Illustrator, or otherwise) as part of a more complete process. Here are a couple of examples:

• High fidelity mockups can be a critical communication tool when working with web design clients. It might seem faster to skip a high detail mockup, but it could hurt later on, because many clients aren’t going to understand how a wireframe will translate to a web browser. A high fidelity mockup can serve as a discussion tool before writing lots of code (only to discover it’s not what the client wanted).
• High fidelity mockups can be very important when working in medium to large sized teams. We often will create high res mockups at Treehouse when planning new courses or designing new features of our site, because it’s a powerful way to sync everyone’s mental model of what a feature will look like or how a project might look once it’s finished.

These two examples have a key difference from the PSD to HTML way of thinking. High detail mockups are still sometimes generated, but not so that they can be “tossed over the fence” to a team of developers or sliced up into code. Rather, Photoshop mockups can be used as a visual aid to discuss ideas. In a PSD to HTML workflow, the Photoshop document represents the final site and it’s expected to look exactly the same in the browser. This is a subtle but important difference.

Different Strokes

Everyone’s workflow is different and nobody knows how to make the perfect website. You should always do whatever is most effective for you and your colleagues. Pushing pixels around in Photoshop is a ton of fun, but I can admit to many occasions when I’ve pushed the pixels too far. The key is to know yourself and what makes you perform at your best. If you have any questions or opinions, I’d love to hear about them in the comments!

The post PSD to HTML is Dead appeared first on Treehouse Blog.