Tuesday, 28 April 2015

How To Define SVG Content for Reuse — The defs, symbol, And use Elements - Vanseo Design

How To Define SVG Content for Reuse — The defs, symbol, And use Elements - Vanseo Design


How To Define SVG Content for Reuse — The defs, symbol, And use Elements

Posted: 27 Apr 2015 05:30 AM PDT

An ability to define code in one location and reuse it in another helps you make your code more modular, maintainable, and readable. SVG provides that ability through elements that define the code and elements that reference it for reuse.

Last week I started a look at how you can structure and organize your SVG code. I introduced you to the generic <g> element along with the <title> and <desc> elements that add additional semantics to your graphics.

Today I want to look at two more grouping elements, <defs> and <symbol>, which allow you to define SVG content for reuse. I'll also talk about the aptly named <use> element, which references and uses the defined content.

The <defs> Element

The <defs> element serves as a container for referenced content. Graphics inside a <defs> element won’t display until referenced elsewhere. They're defined inside <defs>, but need to be called by another element or attribute before they're rendered to the screen.

The <defs> element shares the same content model as the <g> element so anything you can place inside one, you can place inside the other. Typically you’ll wrap <defs> around a <g> element containing graphic elements inside.

To later reference the content you’ll add an id (not a class) to the grouping element that contains the actual elements drawn to the screen and not on the <defs> element itself.

For example I could wrap the group of paths that created the fire in last week’s campfire example with <defs>. Notice I added id=“fire” to the group. The fire will no longer display until it’s referenced.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  
<svg width="300" height="300" viewBox="0 0 300 300">    <title>Campfire</title>    <desc>A campfire burning in a pit</desc>      <g style="fill: #777;">      <title>Fire Pit</title>      <desc>The fire pit in which the campfire is burning</desc>      <path d="M26.851,222.754 L0,222.754 L0,271.758 C0,286.751 14.555,299 32.443,299 L267.52,299 C285.408,299 300,286.751 300,271.758 L300,222.754 L273.112,222.754 L273.112,266.534 C273.112,272.067 267.816,276.484 261.27,276.484 L38.693,276.484 C32.147,276.484 26.851,272.058 26.851,266.534 L26.851,222.754 z" />   </g>     <defs>     <g id="fire" transform="translate(0,10)">       <title>Flames</title>       <desc>The crackling flames of a campfire</desc>       <path d="M101.138,160.949 C94.916,154.464 53.538,110.17 95.277,71.802 C130.054,39.868 135.137,13.003 123.434,-0 C123.434,-0 211.959,33.692 159.877,111.877 C150.998,125.163 128.702,140.843 140.369,173.129 L101.138,160.949 z" />       <path d="M155.503,171.572 C153.624,165.019 145.142,150.746 171.021,122.303 C184.873,107.172 190.104,84.742 191.308,76.301 C191.308,76.301 237.167,100.662 191.576,160.215 L155.503,171.572 z" />     </g>   </defs>     <g transform="translate(0,10)" fill="#530"stroke="#310" stroke-width="0">     <title>Logs</title>     <desc>The logs burning in the campfire</desc>     <path d="M240.344,255.473 L240.344,216.874 L59.378,160.915 L59.378,199.513 z"/>     <path d="M165.259,180.707 L240.321,157.488 L240.321,196.087 L227.627,199.99 z"/>     <path d="M134.519,235.715 L59.419,258.9 L59.419,220.301 L72.151,216.433 z"/>   </g>  </svg>

Here’s how the entire campfire SVG looks now that the flames are placed inside an unreferenced <defs> element.

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

The flames no longer display, though I’ll bring them back later in this post.

How about another example, this time from the spec? Imagine you want to apply the same gradient to a variety of objects. First you define the gradient inside <defs> and then reference it as the fill of an object. Here I added the gradient to both a rectangle and a circle.

1  2  3  4  5  6  7  8  9  10  11  
<svg width="600" height="100">    <defs>      <linearGradient id="gradient">        <stop offset="20%" stop-color="#39F" />        <stop offset="90%" stop-color="#F3F" />      </linearGradient>    </defs>      <rect x="1cm" y="1cm" width="6cm" height="1cm" fill="url(#gradient)" />    <circle rx="50" cx="25" cy="25" fill="url(#gradient)" />  </svg>

We haven’t talked about gradients yet so you’ll have to trust the gradient code. What's important in the example is how the id of gradient is referenced as part of the fill url on both the rectangle and the circle.

Here’s how the entire SVG looks. You can see the gradient that was defined once is applied to both the rectangle and the circle.

The <symbol> Element

The <symbol> element is another grouping element similar to the <defs> element. It’s also not rendered directly. More interesting perhaps, is that symbols can have their own viewBox and preserveAspectRatio attributes.

The attributes mean symbols can be scaled when referenced to work better with whatever is referencing them. Because of this they’ll sometimes make for better reusable content than the <g> element.

Symbols are good for defining anything that will be reused and meant to be independent of the viewport. Icons are one practical example.

Here’s how we could rewrite the <defs> and <g> combination we used to contain the flames in the campfire example using the <symbol> element.

1  2  3  4  5  6  
<symbol id="fire">    <title>Flames</title>    <desc>The crackling flames of a campfire</desc>    <path d="" fill=""/>    <path d="" fill=""/>  </symbol>

I'll show you how a viewBox works on referenced elements next week when I talk about the marker element. The advantage is that you can create symbols that are easier to scale when they're referenced and rendered. I'll talk about symbols more too later in the year when I talk about creating SVG icons.

Now that we’ve seen a few ways to prepare groups of SVG elements for later use, let’s start reusing them.

The <use> Element

The <use> element references another element or group of elements and displays the graphical content at the point the <use> element appears in the SVG document. Inside <use> you reference the id of the element, group, or symbol you want to display.

For example here’s how we could call the fire group from the campfire SVG that we set inside <defs> earlier. The use element references the group through the xlink:href attribute.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  
<svg width="300" height="300" viewBox="0 0 300 300">    <title>Campfire</title>    <desc>A campfire burning in a pit</desc>      <g style="fill: #777;">      <title>Fire Pit</title>      <desc>The fire pit in which the campfire is burning</desc>      <path d="M26.851,222.754 L0,222.754 L0,271.758 C0,286.751 14.555,299 32.443,299 L267.52,299 C285.408,299 300,286.751 300,271.758 L300,222.754 L273.112,222.754 L273.112,266.534 C273.112,272.067 267.816,276.484 261.27,276.484 L38.693,276.484 C32.147,276.484 26.851,272.058 26.851,266.534 L26.851,222.754 z" />   </g>     <defs>     <g id="fire" transform="translate(0,10)">       <title>Flames</title>       <desc>The crackling flames of a campfire</desc>       <path d="M101.138,160.949 C94.916,154.464 53.538,110.17 95.277,71.802 C130.054,39.868 135.137,13.003 123.434,-0 C123.434,-0 211.959,33.692 159.877,111.877 C150.998,125.163 128.702,140.843 140.369,173.129 L101.138,160.949 z" />       <path d="M155.503,171.572 C153.624,165.019 145.142,150.746 171.021,122.303 C184.873,107.172 190.104,84.742 191.308,76.301 C191.308,76.301 237.167,100.662 191.576,160.215 L155.503,171.572 z" />     </g>   </defs>     <g transform="translate(0,10)" fill="#530"stroke="#310" stroke-width="0">     <title>Logs</title>     <desc>The logs burning in the campfire</desc>     <path d="M240.344,255.473 L240.344,216.874 L59.378,160.915 L59.378,199.513 z"/>     <path d="M165.259,180.707 L240.321,157.488 L240.321,196.087 L227.627,199.99 z"/>     <path d="M134.519,235.715 L59.419,258.9 L59.419,220.301 L72.151,216.433 z"/>   </g>      <use xlink:href="#fire" />  </svg>

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

Here the xlink:href attribute points to a named anchor. You can reference something in another file too.

1  
<use xlink:href="path-to-file.svg#fire" />

Unfortunately external references don’t work in IE10 and below.

You'll notice the flames in the graphic show as an unrealistic black. While I set fills (in the form of inline CSS) on the logs and the fire pit, I didn't change the fill from the default black on the flames inside the <defs> element.

I could add a fill and stroke to the group, but I'll show you another way. Instead of adding them to the group you can define the styles in the <use> element when you reference the group.

1  
<use x="0" y="0" xlink:href="#fire" fill="#f00" stroke="orange" stroke-width="5px" />

Here I use the SVG attributes to define the color, but you could add the fill and stroke with inline or external CSS as well.

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

You have to pay attention to specificity, but this ability to define styles on the <use> element means you could instantiate multiple versions of an object each with a different color or stroke.

You can also add any of four optional attributes to the <use> element. The attributes, x, y, width, and height are used to map the referenced content to the current coordinate system. The values x=“0” and y=“0” will be relative to the location of the original referenced element.

Reusing Graphics More Than Once

If you could only reuse <defs> or <symbols> once they wouldn't be all that useful. However, you aren’t limited to a single instantiation with <use>.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  
<svg width="300" height="300" viewBox="0 0 300 300">    <title>Campfire</title>    <desc>A campfire burning in a pit</desc>      <g style="fill: #777;">      <title>Fire Pit</title>      <desc>The fire pit in which the campfire is burning</desc>      <path d="M26.851,222.754 L0,222.754 L0,271.758 C0,286.751 14.555,299 32.443,299 L267.52,299 C285.408,299 300,286.751 300,271.758 L300,222.754 L273.112,222.754 L273.112,266.534 C273.112,272.067 267.816,276.484 261.27,276.484 L38.693,276.484 C32.147,276.484 26.851,272.058 26.851,266.534 L26.851,222.754 z" />   </g>     <defs>     <g id="fire" transform="translate(0,10)" fill="#000">       <title>Flames</title>       <desc>The crackling flames of a campfire</desc>       <path d="M101.138,160.949 C94.916,154.464 53.538,110.17 95.277,71.802 C130.054,39.868 135.137,13.003 123.434,-0 C123.434,-0 211.959,33.692 159.877,111.877 C150.998,125.163 128.702,140.843 140.369,173.129 L101.138,160.949 z" />       <path d="M155.503,171.572 C153.624,165.019 145.142,150.746 171.021,122.303 C184.873,107.172 190.104,84.742 191.308,76.301 C191.308,76.301 237.167,100.662 191.576,160.215 L155.503,171.572 z" />     </g>   </defs>     <g transform="translate(0,10)" fill="#530"stroke="#310" stroke-width="0">     <title>Logs</title>     <desc>The logs burning in the campfire</desc>     <path d="M240.344,255.473 L240.344,216.874 L59.378,160.915 L59.378,199.513 z"/>     <path d="M165.259,180.707 L240.321,157.488 L240.321,196.087 L227.627,199.99 z"/>     <path d="M134.519,235.715 L59.419,258.9 L59.419,220.301 L72.151,216.433 z"/>   </g>     <use x="0" y="-10" xlink:href="#fire" fill="#c00" stroke="orange" stroke-width="5px" />   <use x="20" y="-5" xlink:href="#fire" fill="#e00" stroke="orange" stroke-width="5px" />  </svg>

In this example, I made a few changes from the previous one. First I set a fill of #000 on the #fire group. Next I added two <use> elements instead of one. On each I set fill, stroke and stroke-width values. The fill will override the fill set on the group. Notice that the fill color on each <use> element is slightly different.

I also located the two referenced graphics in different locations so we could see both. Notice that the second <use> element appears on top of the first one. The different fill color adds to the illusion of depth. Here's the resulting graphic with two sets of flames in different locations and with different fills.

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

One last thing I want to mention about the <use> element is you can reference groups and elements that aren't defined inside <defs> or <symbols>. You can reference any group or element with an id.

In the previous example I could have created the #fire group outside of <defs> and have one instance of it display by default. Then I could have called the other set of flames with a <use> element.

Closing Thoughts

An ability to define graphics in one place and reference them for use in another is a powerful tool when working with SVG. It gives you a way to write more modular code that you can more easily maintain.

It also makes it easy to build up larger graphics from several component parts. Imagine drawing a daisy. Instead of a defining a new graphic for each petal, you could define a petal once as a symbol or inside <defs> and reuse it multiple times varying x and y values and adding transforms.

Now imagine a field of daisies with hundred or even thousands of petals and know that the definition for all of them is located in one place making all of the petals easy to modify and maintain.

Hopefully you’re thinking of the possibilities. Next week I want to continue and talk about one more element that is used to hold graphic elements for later reuse. I’ll take a look at the marker element, which has a specific use case.

Download a free sample from my book Design Fundamentals.

The post How To Define SVG Content for Reuse — The defs, symbol, And use Elements appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Friday, 24 April 2015

When Expectations Lead To Complaints About Your Price - Vanseo Design

When Expectations Lead To Complaints About Your Price - Vanseo Design


When Expectations Lead To Complaints About Your Price

Posted: 23 Apr 2015 05:30 AM PDT

Do you think the price of software is too expensive? Do you think updates to software should always be free? Do you complain when you aren't happy with app pricing?


Note: This post includes an audio version. If you don’t see the audio player above, Click here to listen. You can also subscribe in iTunes

I ask these questions because Flexibits recently launched version 2 of their popular calendar app, Fantastical for the Mac. The price of the new version is about three times what version 1 cost and you can imagine how people reacted to the news. Let's just say, many didn't take the news well.

It reminded me of something similar regarding an iOS game called Monument Valley. I'll fill you in on the details momentarily, but it was another case of people being upset with the pricing of an app.

If you don't use a Mac or iOS or just don't care about apps, imagine I'm talking about Adobe and their switch from selling software to selling membership in Adobe Creative Cloud. The changes and reactions are similar to what happened with Fantastical and Monument Valley.

I want to share my initial reaction to both apps as well as my thoughts after I had some time to think more. This may seem like a very unrelated topic, but I think there are some interesting points about about business models, what to charge for your product or service, and managing expectations.

A Tale of Two Apps

Let's start with Fantastical. A few weeks ago I saw the news that version 2 had been released. Like many people using the app I was excited. I enjoy using Fantastical and use it daily. I saw images of the new version, liked the look, and wanted the update.

Unfortunately I thought I was already using Fantastical 2. I am on my iPhone and iPad, but not on my Mac. Thinking I was getting a free update, I checked the Mac app store, but didn't see one.

I thought maybe the announcements had gotten ahead of themselves, but when I went back to read them I realized this was a new app that would require a new purchase. I paid $15 for what I now realized was version 1 and figured there would be a launch day sale on version 2 and it would probably cost $10.

Then I saw the price was $50 (sale price of $40), which is a sizable price increase on what was a $15 app. I thought the new price too much for a calendar app and based on the comments I saw, I wasn't alone.

I had a quick feeling of anger and frustration and I cursed greedy developers under my breath. I went back to reading comments and reviews, cherry picking the ones that felt like I did so I could justify how I was feeling.

Then I went about my day, thinking a little more clearly about Fantastical and it's new price on and off throughout the day.

My experience with Fantastical reminded me about what happened with Monument Valley. I don't remember exactly when the game launched, though I think it was last summer or fall. I do remember the launch itself.

If you haven't seen it, Monument Valley is a game, with a heavy visual influence from M.C. Escher. Imagine moving parts of Escher structures to form new Escher structures that help your character navigate to the next puzzle.

The app is beautiful and sells for $4. The first time I saw a screenshot I wanted it, but I was just about to start my work day. I decided to check on the game later in the day when I assumed I would buy it.

When later arrived and I checked reviews, I found a lot of negative comments. Yes, the game was visually stunning, but it wasn't challenging and within an hour you would probably have finished all the levels.

Some felt like they paid more than they got back based on how much gameplay other iOS games provide at a similar price. The developers promised more levels, but when the levels finally arrived, they were attached to a $2 price tag.

People left 1 star ratings and very negative reviews. That led to a backlash from some Apple bloggers who called all the complainers entitled and cheap.

From the Perspective of the Developers

While I understand the initial anger from customers let's look at this from the side of the developers first. The developers of both apps made a business decision, or rather a number of business decisions.

I can't know with certainty what those decision were as I don't work for either company, however I think I can make some reasonable guesses.

I assume both development teams want to sell to the higher end of the market. They want to sell their apps to people who are more interested in quality than price, people for whom price isn't the main consideration when buying.

As a business owner, I'd much rather sell less of a high margin product than more of a low margin product. Quite honestly you shouldn't be surprised by this strategy from app developers on Apple's platform. It's how Apple operates so why expect different from developers for their ecosystem.

The developers of Fantastical had been selling a mini app that lives in the menu bar on Macs. It accessed Apple's default calendar and in many ways serves as a better interface for Apple's product. This was a $15 mini calendar that was reasonably priced, though still more than I wanted to pay for a calendar.

Flexibits decided to add a full calendar to the mini calendar in the menu bar, and they decided to charge $50 for everything. They made a decision to compete with other calendar apps like BusyCal.

I'm sure they knew some people would be put off by the price increase and calculated that enough people would still buy the app to offset any loss in revenue from those who won't. For every 50 people that purchased version 1, if 15 of them purchase version 2 it'll be a wash in revenue, though with many fewer customers needing support.

This is just a guess, but I have a feeling the developers were also motivated by wanting a full calendar for themselves.

I completely understand the business decisions and likely would have made the same ones if it were me. I do wonder if a large discount, say 50%, would have stemmed some of the criticism. At 50% off the app would cost $25 for existing Fantastical customers. I think the large price increase combined with the smaller discount felt like a slap in the face to some.

I think the developers of Monument Valley made similar business decisions about serving the higher end of the market. True it is a $4 app, but many iOS games are $1.99 or less.

The main draw of the app is the visual treatment. The focus of the developers is on the game's aesthetics and no matter what aesthetic treatment there's a limit on how many levels they can continue to create without additional revenue. They opted to charge for those additional levels.

This isn't anything new. It's the revenue model of arcades. I remember feeding quarters (Yep, quarters — I'm that old) into the machines to play again. Now you'll pay $2 for another set of levels.

My suggestion would be to make the initial app free to get people in and then sell them additional levels over time. perhaps the app could start with more free levels initially to get people hooked on the game before selling more. The developers could have offered more gameplay for the initial price, though they can see their numbers better than I can and they know if they chose the right strategy.

From the Perspective of the Customers

Like I said, I get why customers were upset with both companies. I had a similar initial reaction to both apps as many others.

There's no question a large number of the complaints were from people who do exhibit a strong sense of entitlement. The developers can likely ignore these people as they aren't real customers and they aren't likely to buy from again or at all.

However, not everyone is complaining because they feel entitled. Some people have reasoned arguments for why they're upset with the pricing of both apps.

Let me start with Monument Valley this time. A number of people felt the initial gameplay didn't offer enough for the price. Some to the point of feeling cheated.

It wasn't about the absolute price of $4. That's not a lot of money, but the game offered little challenge and lasted about an hour before you'd finish every level. That seems low based on other games selling on iOS.

A few more hours of gameplay, something that couldn't be finished in a single sitting, would be more in tune with the expectations that have been set by several years of iOS games.

When the developers said more levels were coming, some customers thought that meant they'd be free. I don't think the developers ever promised free levels, but given the timing of their response it seemed to be the indication to some.

When the new levels came with a $2 price tag some complained and complained based on the expectation of free levels and not specifically because of the price. I don't think most of these people had a problem paying $2 for more levels, but not until they felt they received the $4 worth of levels they had already purchased.

For some people this is about value and feeling that the developers of the game didn't provide enough value compared to similar and similarly priced apps.

In the case of Fantastical, a fair amount of the complaints are again from people with a strong sense of entitlement. I didn't see it to the same extent given Fantastical already had a higher price tag, but it was there.

Still some have reasoned arguments. $15 to $50 is a large price increase, especially for an app some people don't use enough to justify the increase.

Keep in mind that version 1 of Fantastical was a menu bar app and not a full calendar app. Its customers are people who are fine using another calendar and using Fantastical as a quick and easy interface to that calendar. Now they're being asked to pay the price of a full calendar app to upgrade their menu bar app.

Again it was the expectation and I'll use myself as an example. Initially I thought I had version 2 and was awaiting a free update. Then I leaned the app was a new app and I'd have to pay for it again. That's broken expectation #1.

I adjusted and figured the price would be inline with the previous price. I thought $10 on sale, but anything up to $20 would have felt perfectly normal. When I saw a price of $50 ($40 on sale) it was broken expectation #2.

Then I thought about what a full calendar app was worth to me and I projected that value onto calendar apps in general. My feeling was the app was overpriced and should have been $20 at most and I found plenty of comments and reviews to agree with me.

I've paid $50 and more for apps before. My negative feelings weren't about the absolute price, but the price in comparison to my expectations about what the price would be.

Again, there are many people who just expect everything for free and unfortunately app developers will get flack from people for charging anything. It's wrong, but it's going to happen.

But there are people expressing genuine disappointment with the pricing not because they're cheap or feel entitled. They don't have a problem buying apps in general, but they do have specific reasons why the particular prices of these apps were too much.

You and I might not agree with their reasons. The developers might not agree with their reasons either, but that doesn't make the reasons any less valid. They're real reasons from real customers for why they won't buy an app.

I have to say I was disappointed in a lot of Apple bloggers for lumping everyone into the entitled group when Monument Valley was being criticized. Their message was if you don't buy the app, you're cheap and entitled and want everything for free. It was similar, though to a much lesser extent, with Fantastical.

I'm also disappointed with anyone who calls the developers of these apps greedy. I'm sure there greedy app developers, but I think the vast majority are people like you and me, good and decent people just trying make a living.

The developers made a business decision to serve a certain market at the exclusion of other markets. That's a tough decision, but one I understand and agree with. It's not any different than firing a client, which I've done a few times over the years.

The decision may turn out to be less than what the developers hope or it may turn out exactly as they hope. Either way it's their right to make either decision.

Value, Expectation, and Price

Forget about the entitled people. They aren't future customers. For the people making reasoned arguments, the specific price isn't the issue. I would never argue that $2 is a lot of money, though that is coming from a first world perspective. In some parts of the world $2 is a lot of money.

Speaking again from a first world perspective I don't think $50 is a lot of money. If it brings back more than $50 of value in return, it's not expensive.

The initial gut feeling comes from the disconnect between the actual price and the expected price. Where Monument Valley is concerned for right or wrong, people expected new levels to be free and they complained when they weren't. Where Fantastical is concerned people expected an app similar in price to the previous version and possibly with a 50% discount.The reality was a $50 full calendar app.

I think a significant amount of the angry reaction would have been lessened had the developers of both apps set better expectations.

Instead of the big one day launch, they could have broken the news slower, over the course of a week say and set the expectation closer to the reality. They would probably still get some initial angry reaction, but there would be no app yet to rate or review poorly and by the time there was, the anger would have subsided.

In the case of Monument Valley the developers could have been clearer that they would charge for new levels. They could have also offered one at least one set of free levels before charging for more.

In the case of Fantastical the developers could have offered a lite version of the app that includes only the menu bar version. They could have charged $20 or even $25 with the full calendar being an in app purchase taking the total price up to $50. Perhaps they did and decided against it, but I think it would have kept most of the existing Fantastical customers who only want the menu bar app.

Then again they know their numbers better than I do and maybe losing some customers in favor of those who aren't put off by the price is the best decision for their business. Maybe ripping the band aide off all once was the better option.

What Did I Buy?

You might be wondering after all this if I purchased either app.

With Monument Valley I asked myself if I would rather have $4 or a game to entertain me for an hour. It's not too hard to find things to entertain me. The hard part is deciding what to choose.

I decided to find something else to entertain me, which wasn't difficult, and to save the $4 for another purchase. I figured I could look at the work of M.C. Escher for an hour and come away with more value for my time. As nice as the game looks, it's still derivative of the original.

I was never a big fan on throwing all those quarters into the arcade either. It always felt like more money than the value I gained in return. I was happy to watch friends play and it didn't cost me anything.

$4 and $2 are hardly expensive. I can guarantee I'll waste more on something this month or week and possibly today. For me the value wasn't there with Monument Valley. It's hard to justify $4 on an hour of gameplay when I could spend that same $4 to rent a two hour movie.

That doesn't make the app or the developers bad in any way, but it does mean the game isn't for me. I suspect many who did buy the game and the levels are happily both. I also suspect many people made the same decision I did.

With Fantastical there was something about the app that made me want it. I've used version 1 daily since buying it and a large part of what I felt was because I wanted version 2, but wasn't expecting a $50 or $40 price tag.

I'm hardly a power user of calendars. I don't have a lot, or really any, meetings and I tend to work off To Do apps like Things as opposed to a calendar.

I purchased Fantastical in the first place because it was a menu bar app. I was fine with Apple's default calendar, but I grew tired of opening and closing it or leaving it open all the time on an older computer. I wanted a menu app and I found one.

I didn't need the new version with the full calendar to do what I wanted. The list of new features looked useful, but useful for someone not named me.

Still, I do use and rely on a calendar for one thing. I use it as an editorial calendar for what I write on this site. I plan the content I'll write for the month and add events to the calendar. I add notes to each so I can see what stage a post is in and see the progress I've made and how much work I have left.

That has value to me. It lets me quickly see the work I've done and have left to do. It saves me time and if it saves even an hour a year, which I'm sure it far exceeds, then it should be worth my hourly rate to me. How is $50 not fair?

I've had Fantastical 1 for a year and a half and paid $15 for it, which works out to $10 a year. I think this is the first time the developers have asked for more money in three years. Assuming it's the same between now and the next version.

  • $40 ÷ 3 = $13.33
  • $50 ÷ 3 = $16.67

It's hard to argue against the price when I was happy spending $10 a year and would now pay $13.33 a year. It's not as much of an increase for me as it seems.

Even after seeing these yearly numbers, I wasn't sure if the new version offered anything for me besides looking nicer and it was still hard for me to justify the price. I did the sensible thing and downloaded the trial.

Between playing with the trial for a day and reading up on the features of the full calendar, I thought of a better way to set up my editorial calendar using one of the new features, calendar sets, and color coding, which I could have used previously. The color coding helps me better distinguish the stages of each post. My calendar is now quicker and easier to read at a glance.

I also thought why not multiple editorial calendars. In addition to writing here, I write books and guest articles. Why not use a calendar with them too. Then I thought why not create one for client work. I don't expect I'll work to the calendar, but I could probably schedule projects better with one.

Then I thought of an entirely different use. Instead of using a calendar to schedule future work, I could use it to show the work I finished and how I actually spent my time. I can take information from my time tracking app and add new entries to the calendar at the end of the day.

This use of the calendar will enable me to quickly look over a week or month and see where my time goes. It can become part of my weekly productivity reviews.

I bought Fantastical 2 the next morning. I keep thinking of new ways to use it and I don't mind opening and closing the app, especially as it has keystrokes combinations to make it easy.

Closing Thoughts

I understand both sides of this issue. Developers need to earn a living and they make business decisions to improve their businesses. That's irrelevant to their customers, though. Customers don't buy your app because you worked hard on it. They buy it because the perceived value is greater than the price.

With both Fantastical and Monument Valley the decisions made by developers angered a significant amount of customers, but ultimately the developers think their decisions will be best for their business and they have that right. I probably would have made similar decisions in their position.

There are two types of people complaining. One group is made up of people with a strong sense of entitlement who think anything they want should be free. Even a nickel or dime is highway robbery to them.

There's little you can do about these people so don't worry about them. They'll leave poor reviews, but others will leave positive ones for counterbalance. App developers also have the trick of a new point release which will render all reviews to appear as reviews of older versions of the app.

However, the second group consists of real customers who are also expressing anger over the price, but their anger comes from valid reasons. This group is very consistent with their reasoning. Whether you agree with them or not they are worth listening to, because they are paying customers or would be other than the reasons they're giving.

As a customer if you don't see the value then don't buy the app. However, before you make that assumption I'd suggest you think about the value you get and what you're being asked to pay.

$50 is more than $15, but it's hardly a lot of money if that $50 will cover a couple or three years of the app. It's also not much of a business expense. Any business related app that saves you an hour of time is easily with $50 or more.

Developers would do well to [http://kensegall.com/2015/04/apple-the-customers-shoes/set expectations better]. This is what I hope you take away from this post, that setting expectations about price and the value you'll deliver for that price will lead to less angry customers.

If version 1 of your app sells for $15, then a $50 version 2 is going to upset a lot of people. The $15 price of version 1 attracts customers who are willing to pay $15 for an app and it sets expectations about the price of version 2. People will complain if the real price is too far off from their expected price.

If you leave room for interpretation about there being a price on a future update and some people interpret the price will be free, then they'll complain when that price is anything else.

Understand how your customers will react to the unexpected and do what you can to change their expectation so they're more aligned with reality.

There's nothing wrong with making the decision to develop a new app with a larger price tag or to charge for game levels that take time to produce. Just remember that if you do a good job setting expectations for price changes or for charging any price you'll have less unhappy customers who leave angry reviews that convince others not to buy your app.

Download a free sample from my book Design Fundamentals.

The post When Expectations Lead To Complaints About Your Price appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Tuesday, 21 April 2015

How To Structure Your SVG Code — The <g>, <title>, And <desc> Elements - Vanseo Design

How To Structure Your SVG Code — The <g>, <title>, And <desc> Elements - Vanseo Design


How To Structure Your SVG Code — The <g>, <title>, And <desc> Elements

Posted: 20 Apr 2015 05:30 AM PDT

What's the best way to organize your SVG code? If all you want to draw is a line or simple shape there's not much to organize, but what about SVGs with multiple shapes and lines that combine to form a more complex whole?

Earlier in the year when I talked about SVG, I walked you through creating shapes, lines, polylines, polygons, and paths. In the examples for those posts, the graphics I created with these elements were all very simple. A circle here and a rectangle there, a line here and a curve there.

Let’s change that. Today I want to talk about how you can organize and structure your SVG code when working with more complex graphics and over the next few weeks I’ll share how you can group your code and even better, how you can reuse parts or the whole of any graphic elements you create.

A More Complex Example

Like I said the examples to this point have generally featured rectangles and circles. There’s not much to organize and structure when we have a single shape inside an <svg> element.

Since I’m not someone who gets mistaken for a graphics wizard, I took an easier path and used one of the standard shapes in iDraw and exported it as an .svg file.

Here’s the code after I removed the xmlns information and some automatic grouping iDraw added.

1  2  3  4  5  6  7  8  
<svg x="0" y="0" width="300" height="300" viewBox="0, 0, 300, 300">    <path d="M26.851,222.754 L0,222.754 L0,271.758 C0,286.751 14.555,299 32.443,299 L267.52,299 C285.408,299 300,286.751 300,271.758 L300,222.754 L273.112,222.754 L273.112,266.534 C273.112,272.067 267.816,276.484 261.27,276.484 L38.693,276.484 C32.147,276.484 26.851,272.058 26.851,266.534 L26.851,222.754 z" fill="#000000"/>    <path d="M240.344,255.473 L240.344,216.874 L59.378,160.915 L59.378,199.513 z" fill="#000000"/>    <path d="M101.138,160.949 C94.916,154.464 53.538,110.17 95.277,71.802 C130.054,39.868 135.137,13.003 123.434,-0 C123.434,-0 211.959,33.692 159.877,111.877 C150.998,125.163 128.702,140.843 140.369,173.129 L101.138,160.949 z" fill="#000000"/>    <path d="M155.503,171.572 C153.624,165.019 145.142,150.746 171.021,122.303 C184.873,107.172 190.104,84.742 191.308,76.301 C191.308,76.301 237.167,100.662 191.576,160.215 L155.503,171.572 z" fill="#000000"/>    <path d="M165.259,180.707 L240.321,157.488 L240.321,196.087 L227.627,199.99 z" fill="#000000"/>    <path d="M134.519,235.715 L59.419,258.9 L59.419,220.301 L72.151,216.433 z" fill="#000000"/>  </svg>

The SVG is made up of six different paths inside an <svg> element. All the paths are filled with black (#000000). Both viewport and viewBox are aligned at their origins and each is 300px wide and 300px high.

Here’s the graphic produced by the code.

While you probably can’t look at the code and instantly determine which path is creating which shape in the campfire, it’s easy enough to see there are six distinct shapes in the campfire graphic and six different paths in the code. Logic would suggest each shape is created by one of the paths.

  • A single path creates the fire pit at the bottom
  • Three paths create the two logs in the campfire
  • Two paths create the flames of the fire

Wouldn’t it be nice to organize these three parts of the graphic and group the paths that created each in some way?

Document Structure — Grouping

You wouldn’t create an entire web page and place all your code inside a single <div> with no other structure. We build pages with divs inside divs. We use sections and headers and other block level elements to organize our code.

Like the content you place in different HTML elements, grouped SVG elements can be styled similarly and differently from the elements in other groups. Grouped elements can be animated independently for more realism and you can attach mouse events to groups for more interactivity.

Like HTML, SVG provides a number of elements such as such as <g>, <desc>, <defs>, <symbol>, and <use> to structure and organize your graphics. I’ll get to the first two in this post and the latter three in next week's post.

The <g> Element

The <g> element is a generic container for grouping related graphic elements. You might think of it like a generic <div> or maybe similar to layers in a graphic editor.

In our campfire SVG you can probably guess how many groups we’ll create and what will be inside each. You’ll likely assign a class and possibly an id to any group you create to provide a hook to the group.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  
<svg width="300" height="300" viewBox="0 0 300 300">   <g class="fire-pit">     <path d="M26.851,222.754 L0,222.754 L0,271.758 C0,286.751 14.555,299 32.443,299 L267.52,299 C285.408,299 300,286.751 300,271.758 L300,222.754 L273.112,222.754 L273.112,266.534 C273.112,272.067 267.816,276.484 261.27,276.484 L38.693,276.484 C32.147,276.484 26.851,272.058 26.851,266.534 L26.851,222.754 z" fill="#000000"/>   </g>     <g class="flames">     <path d="M101.138,160.949 C94.916,154.464 53.538,110.17 95.277,71.802 C130.054,39.868 135.137,13.003 123.434,-0 C123.434,-0 211.959,33.692 159.877,111.877 C150.998,125.163 128.702,140.843 140.369,173.129 L101.138,160.949 z" fill="#000000"/>     <path d="M155.503,171.572 C153.624,165.019 145.142,150.746 171.021,122.303 C184.873,107.172 190.104,84.742 191.308,76.301 C191.308,76.301 237.167,100.662 191.576,160.215 L155.503,171.572 z" fill="#000000"/>   </g>     <g class="logs">     <path d="M240.344,255.473 L240.344,216.874 L59.378,160.915 L59.378,199.513 z" fill="#000000"/>     <path d="M165.259,180.707 L240.321,157.488 L240.321,196.087 L227.627,199.99 z" fill="#000000"/>     <path d="M134.519,235.715 L59.419,258.9 L59.419,220.301 L72.151,216.433 z" fill="#000000"/>   </g>  </svg>

Here I organized the six paths into three groups (after figuring out which path created which shape), one for the fire pit, one for the logs, and one for the flames. I placed the paths for each inside different group and added classes to each.

When you apply CSS styles to the group class all the elements inside the group will inherit those styles, though each element can also override the style of the group by having styles added directly to it.

The <title> and <desc> Elements

The <title> and <desc> elements are probably what you’d expect them to be based on their names. Either can be accessed by assistive devices like screen readers. Browsers will likely grab what’s inside the title element and use it as a tooltip when mousing over the graphic.

Think of them the way you would think about the <title> and <longdesc> attributes you place on an image. You should use the attributes to describe the SVG for anyone who can’t see it. Your outermost <svg> element should always have at least a title.

Here's the previous example again, this time with titles and descriptions added.

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  
<svg width="300" height="300" viewBox="0 0 300 300">   <title>Campfire</title>   <desc>A campfire burning in a fire pit</desc>     <g class="fire-pit">     <title>Fire Pit</title>     <desc>The fire pit in which the campfire is burning</desc>     <path d="M26.851,222.754 L0,222.754 L0,271.758 C0,286.751 14.555,299 32.443,299 L267.52,299 C285.408,299 300,286.751 300,271.758 L300,222.754 L273.112,222.754 L273.112,266.534 C273.112,272.067 267.816,276.484 261.27,276.484 L38.693,276.484 C32.147,276.484 26.851,272.058 26.851,266.534 L26.851,222.754 z" fill="#000000"/>   </g>     <g class="flames">     <title>Flames</title>     <desc>The crackling flames of a campfire</desc>     <path d="M101.138,160.949 C94.916,154.464 53.538,110.17 95.277,71.802 C130.054,39.868 135.137,13.003 123.434,-0 C123.434,-0 211.959,33.692 159.877,111.877 C150.998,125.163 128.702,140.843 140.369,173.129 L101.138,160.949 z" fill="#000000"/>     <path d="M155.503,171.572 C153.624,165.019 145.142,150.746 171.021,122.303 C184.873,107.172 190.104,84.742 191.308,76.301 C191.308,76.301 237.167,100.662 191.576,160.215 L155.503,171.572 z" fill="#000000"/>   </g>     <g class="logs">     <title>Logs</title>     <desc>The logs burning in the campfire</desc>     <path d="M240.344,255.473 L240.344,216.874 L59.378,160.915 L59.378,199.513 z" fill="#000000"/>     <path d="M165.259,180.707 L240.321,157.488 L240.321,196.087 L227.627,199.99 z" fill="#000000"/>     <path d="M134.519,235.715 L59.419,258.9 L59.419,220.301 L72.151,216.433 z" fill="#000000"/>   </g>  </svg>

Notice that each group now has a title and brief description. I gave the outermost SVG element both a title and description as well.

If you mouse over any of the graphics you should see a tool tip with the title of the group. If you mouse over any empty areas in the viewport, the tool tip will show the title on the SVG element.

A campfire burning in a fire pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

Adding CSS to SVG Groups

I added a class to each of the different groups in order to style what's inside each group similarly. For example here’s a little CSS to give the flames a different fill color along with a stroke color and width.

1  2  3  4  5  
.flames {    stroke: green;    stroke-width: 5px;    fill: #f00;  }

You can override a style given to the group by applying it to the elements in the group directly. For example I don’t think green is the right color to outline the flames. Orange will work better.

1  2  3  
.flames path {    stroke: orange;  }

Note: While I'm showing CSS from an external file in this section, I'm adding the CSS inline to the graphics to make things a little easier to display here.

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

While I’m at it, I might as well add some color to the other groups.

1  2  3  4  5  6  7  
.logs {    fill: #530;  }    .fire-pit {    fill: #777;  }

Since you can add styles as inline or external css, or attributes directly on the elements, you have to be aware of the CSS cascade and CSS specificity. A fill added as an attribute to any of the paths will override a fill set on the group. The attribute can be overridden with more specific external CSS or inline CSS on the same element as the attribute. Know your CSS specificity rules.

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

One drawback to groups is they don’t allow for x and y attributes to change the group's position. You can, however, use transforms on groups. For example I think the logs sit a little too high above the fire pit so I’ll move them down just a bit.

1  2  3  
<g class="logs" transform="translate(0,10)">    <!-- paths, title, desc for logs here -->  </g>

That means the flames will also need to come down a little too.

1  2  3  
<g class="flames" transform="translate(0,10)">    <!-- paths, title, desc for flames here -->  </g>

Here's the entire SVG one last time with the transformations included. The graphic will look the same, though if you compare it to the rest, you can see the logs and flames are now a little lower and closer to the fire pit.

A campfire burning in a pitThe fire pit in which the campfire is burning The crackling flames of a campfire The logs burning in the campfire

Hopefully you can see how easy it is to work with the generic group created by the <g> element. I trust you won't have any issues with <title> or <desc> either.

Closing Thoughts

Organization is important once you start building up SVGs from multiple shapes, lines, paths, polylines, and polygons. It'll help you style, animate, or interact with the different parts of your SVG independently of each other.

The <g> element is the most generic container you can use to group and organize your SVG elements. Elements like <title> and <desc> will help you communicate additional information to assistive devices and any other user agent that cares to make use of them.

The <g> element isn’t the only way to group elements, though. It's just the first we've encountered. Next week I’ll show two more elements to help organize your SVG, <defs> and <symbol>, and then I'll show you how you can define a graphic in one place and reuse it in another.

Download a free sample from my book Design Fundamentals.

The post How To Structure Your SVG Code — The <g>, <title>, And <desc> Elements appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now