Skip to content

Commit

Permalink
New post on the history of MSDN to Docs to Learn
Browse files Browse the repository at this point in the history
  • Loading branch information
Duncanma committed May 14, 2023
1 parent 797c1b8 commit 13d51fc
Show file tree
Hide file tree
Showing 6 changed files with 115 additions and 11 deletions.
5 changes: 2 additions & 3 deletions content/Blog/assessing-your-site-for-seo.md
Expand Up @@ -7,7 +7,6 @@ tags:
- Coding
- Self-Assessment
- SEO
techfeatured: true
description: A beginner's guide to seo going through a step by step tutorial to assess your own site
---

Expand Down Expand Up @@ -62,7 +61,7 @@ easier or harder for it to understand our pages.

You can't call Google up and ask them if your site is written correctly,
but you can do the next best thing through a few special types of
searches and the Google Search Console.
searches and the Google Search Console.

### What's showing up in Google?

Expand Down Expand Up @@ -459,7 +458,7 @@ What you want to check here, as a site owner, is:
- Do I have a robots.txt file? (just add /robots.txt to your domain in
a browser and see)
- Does it contain a link to a sitemap?
- Does that sitemap (just paste that link into the browser) exist, and
- Does that sitemap (just paste that link into the browser) exist, and
does it seem to contain all my URLs? (if you have 1000s of URLs, I
don't expect you to do an exhaustive audit, but read through and see
if it seems to include everything, or search for pages you are
Expand Down
1 change: 1 addition & 0 deletions content/Blog/do-as-little-as-possible.md
Expand Up @@ -7,6 +7,7 @@ tags:
- Coding
- Performance
- Scalability
techfeatured: true
---
One of the keys to scalability in software systems is to reduce the
amount of work you do per action. In a website, think of this as the
Expand Down
4 changes: 2 additions & 2 deletions content/Blog/domain-names.md
Expand Up @@ -5,6 +5,7 @@ type: posts
tags:
- Web Development
- Security
- Information Architecture
techfeatured: true
description: If your company has a core domain, leverage it for all your sites, instead of making new ones.
---
Expand All @@ -17,7 +18,7 @@ I saw the positive and negative impact of proper domain choice recently, when re

![Search results showing many results around Hawaii and COVID-19](/images/domains/FullSearchResults.png)

The first link is to travel.hawaii.gov, an official site run by the Hawaii state government, and the best place to go… but the second link seems useful too and is located at safetravelshawaii.com. This isn’t a scam site as far as I can tell, but it isn’t the official government program, and exists to promote a specific company’s products and services. So far so good, the proper domain name was used for the official site and made me feel safe using the information on those pages, but if I look a bit further down in the search results…
The first link is to travel.hawaii.gov, an official site run by the Hawaii state government, and the best place to go… but the second link seems useful too and is located at safetravelshawaii.com. This isn’t a scam site as far as I can tell, but it isn’t the official government program, and exists to promote a specific company’s products and services. So far so good, the proper domain name was used for the official site and made me feel safe using the information on those pages, but if I look a bit further down in the search results…

![Search result showing a site called hawaiicovid19 that seems to be from the Hawaii government, maybe?](/images/domains/SearchResult.png)

Expand All @@ -32,4 +33,3 @@ Now that I’ve been thinking about this, I am seeing similar issues everywhere,
{{% note %}}
FYI, John Oliver had [a great segment about the Equifax security breach](https://www.youtube.com/watch?v=mPjgRKW_Jmk) that pointed out this exact issue. Equifax (that has a nice authoritative domain of Equifax.com) setup a new site at www.equifaxsecurity2017.com to deal with this specific event, and the HBO host showed that anyone can create a site that sounds legit by spinning up www.equifaxfraudprevention.com.
{{% /note %}}

106 changes: 106 additions & 0 deletions content/Blog/evolution-of-microsoft-documentation-sites.md
@@ -0,0 +1,106 @@
---
date: 2023-05-14T14:34:56-07:00
title: The evolution of Microsoft documentation sites
type: posts
tags:
- Microsoft
- Information Architecture
- Web Development
techfeatured: true
---

I ran through this history recently with someone at work and thought
maybe I should post it up online for posterity's sake.

> This is all in the past, so why is it interesting now? Well, domain
> names and site branding is part of your 'information architecture' and
> it is almost always a bit of a compromise. At the highest level, you
> have your domain that is equal to your brand (Microsoft.com,
> Stripe.com, Toyota.com, etc.) so that's easy to create and to
> understand what should live at that address. For anything else though,
> paths below that root, or subdomains, you are essentially creating a
> categorization of content, and that will evolve over time.
> Also, [a related discussion of domain names and why you should always **use your domain** instead of making random new ones](/blog/domain-names).
## The MSDN and TechNet days

Back in the 90's Microsoft's developer documentation lived under the
brand "MSDN" (Microsoft Developer Network) and content aimed at 'IT
Professionals' (folks who deployed software, administered servers, wrote
more scripts than application code) lived on another site "TechNet"
(Technical Network I guess?). As someone who worked as a writer and
developer on the team behind these sites, I can tell you that this
division was always a little fuzzy. Developers often need to install and
administer servers (SQL Server for example), and many 'IT Pros' wrote
code. The dual sites often led to a confusing experience for users, the
documentation to install Exchange Server was on one site, while the
documentation on it's APIs lived somewhere else. Real old-timers, like
myself, will remember that these sites were originally just the web
presence for a pair of "content on CD" subscription systems, similar to
how Netflix used to be a way to sign up to get DVDs delivered in the
mail.

## Oops, we ignored our sites, and they got old and stale

Eventually, both sites (which ran on essentially the same code, at least
when I worked on them, with customizations) were understaffed and
ignored for many years. It was decided that they should be replaced,
that their brand names were associated with the old Microsoft, and that
there was little value in trying to update the code base.

A new site would be created, and it would be the home of all types of
technical documentation, regardless of the audience. For a time, the
domain '[developer.microsoft.com](https://developer.microsoft.com)' was considered (yes, it does exist as
essentially a routing page), because that was a common pattern for
companies posting their technical docs (see
[developers.google.com](https://developers.google.com), [developer.twitter.com](https://developer.twitter.com),
[developer.amazon.com](https://developer.amazon.com/), and others). This hits on our
'information architecture' problem though... not all content that would
live on this site is for developers, some of it is for the database
administrator, the data scientist who uses Power BI, the no-code user
that is going to use Power Apps, the network administrator who needs to
configure Windows group policy, etc. Developer as the top-level brand
would be excluding all those people.

> Small note here, as someone who was present for these discussions, I
> don't believe there was real data confirming this would exclude anyone, or
> that it would be a problem. There was fear it would be though, and
> that is often enough when a large group of people at a company need to
> agree on a decision.
## Docs arrives as the new unified home of documentation

The very safe, and hard to argue with, domain of "docs.microsoft.com"
was eventually chosen, along with the brand of "Microsoft Docs".
Everything on this site would be documentation, so it was perfect. It
was only 'technical' documentation, docs for users of Microsoft Office,
or Windows, were not included, and that did cause some discussions back
and forth over the next few years. It was often suggested that maybe all
documentation should live under docs.microsoft.com, but other than a few
random bits of non-technical content, it never happened.

This brand and domain launched in 2016 and worked well with no issues for
a few years, while developer.microsoft.com was kept around as a general
landing page for developer topics, routing to a bunch of different sites
including docs.microsoft.com.

## Learn is here (to stay?)

In 2018 though, it was decided that we needed a large amount of
interactive, guided learning material. Courses, modules, knowledge
tests, etc. All of which would live on the docs site, under the /learn
path. It was branded "Microsoft Learn" and was very popular. To a lot of
people, especially those that worked on this new learning content, this
was **not** documentation though, and it felt odd to them that it was
under docs.microsoft.com. This concern was voiced often and loudly for a
few years, until finally in September of 2022, docs.microsoft.com was
redirected to learn.microsoft.com and the entire site was rebranded
"Microsoft Learn". Documentation was moved to /docs as part of this
change. Learn is a very broad (or vague, depending on your mood) term,
so hopefully it will be able to stay as the brand through many future
evolutions of the content.

> FYI, the above *history* is based on my own recollection of events.
> I was a user of MSDN/TechNet back in the 90s, joined Microsoft in
> 1999, worked on MSDN from 2001 to 2005, then joined Microsoft Docs as
> an engineering manager right before it was ready to launch.
8 changes: 3 additions & 5 deletions content/Blog/referrer.md
Expand Up @@ -4,8 +4,7 @@ title: Don't depend on Referrer info
type: posts
tags:
- Web Development
description: Determining the source of traffic to your pages is often done via the referral information passed in the request, but this information is often unavailable or inaccurate.
techfeatured: true
description: Determining the source of traffic to your pages is often done via the referral information passed in the request, but this information is often unavailable or inaccurate.
---

Over the years, many people have asked me to give them data on, or act
Expand Down Expand Up @@ -148,14 +147,13 @@ that **you** can still use this data to understand user journeys on
As a web developer though, what the main takeaway from all of this is
that **in most cases you cannot determine the page a user is coming from when they visit your site**. You can, in some cases, determine the
origin (so you can tell this is traffic from Google, Bing, Twitter, etc.), but not in every
case depending on the way the source site is configured.
case depending on the way the source site is configured.

If you are building a feature that requires you know the source of some incoming
traffic, then **you should change the incoming URL**. Adding a query
param of `?traffic_source=<foo.com>` would work or you can use campaign
IDs (details depend on your analytics, but you'll have seen examples like WT.mc_id in URLs all over the web) that have the advantage of already being supported by many types of
analytics software.
analytics software.

If you have no control over the source page/link, then honestly, you are out of luck. You might pick up some referrer
information, from older browsers, but you **cannot depend on this** to work in most cases.

2 changes: 1 addition & 1 deletion themes/hello-friend-ng

0 comments on commit 13d51fc

Please sign in to comment.