Monthly Archives: March 2014

Drawing an Anatomically Correct Directional Arrow

Design, Graphics, User Interface

It’s far down the list of issues I’ve ever dealt with, yet the ubiquitous directional arrow has always bothered me a bit because the blades are too thick. This is because it is naively rendered using the same stroke width. I took a look at it and realized that the proper blade thickness should be based on the blades’ angle. This can be determined mathematically by taking the square root of the cosine, e.g.

clip_image001.gif

So a line that was 3 pixels wide becomes 2.53 pixels wide (3 x .840896). Here’s a schematic showing the construction steps (click or tap to embiggen):

arrow_drawing_schematic_4

The effect is less pronounced at shallow angles, more so at steeper angles (with a corresponding need for correction):

clip_image003.png

Update:

The morning after originally publishing this post, I saw a proper example of one of these arrows…on a North American Van Lines moving truck. Who woulda thunk? But a little analysis of the logo with an arrow overlaid that has blades at a 37.5° angle shows their designer was, uhm, pardon the pun, thinking along the same lines:

NorthAmericanVanLines

NorthAmericanVanLines2

It’s very close to fitting the formula.

Web API, JSON by Default in Web Browsers

CSharp, JSON, Web API

I use a few methods for examining and debugging JSON output. One of those is to view it in a browser. If that browser is Internet Explorer, then the file just gets opened automatically in Notepad++ (which, nicely, will also just keep updating an existing file, avoiding tab clutter). There, I use the JSON Viewer plugin, which is decent enough, if a bit unpolished. If the browser is Chrome, I use JSONView. One advantage is that if the JSON doesn’t end up formatted, you know right away it isn’t valid. But, unlike JSONLint it can’t tell you where the problem is.

For whatever inane reason (XML is dead, right? :-)) Chrome likes to tell servers that it accepts XML. So your “purist” Web API that is set up to deliver only JSON gets this request and fails to serialize into XML. So Chrome just gets a big, nasty error message back.

Fortunately, there is way to head this off at the pass. In the Web API global.asax.cs file you can remove the XML formatter (if you’re never going to use it):

using System;
using System.Linq;
using System.Web;
using System.Web.Http;

namespace GeoDataAPI
{
    public class Global : HttpApplication
    {
        protected void Application_Start(object sender, EventArgs e)
        {
            GlobalConfiguration.Configure(WebApiConfig.Register);

            // Ignores browsers like Chrome requesting xml.
            var config = GlobalConfiguration.Configuration;
            var appXmlType =
                config.Formatters.XmlFormatter.SupportedMediaTypes.FirstOrDefault(t => t.MediaType == "application/xml");
            config.Formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);
        }
    }
}

Another approach is to use 

config.Formatters.JsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));

But I found this caused a problem with third-party data that contained HTML break tags. The JSON was sent out with carriage returns, which caused it to be invalid. If you don’t need XML, I recommend the other way of doing this.