Category - web

1
Now Accepting Clients
2
Displaying SharePoint Blog Posts In Your Team Site
3
Naming Internal Web Applications

Now Accepting Clients

A while back, I decided I was ready to once again make the leap to accept contracts for web design work. I’ve decided to turn this into an at least part-time business.

As such, I’m happy to announce that I’ve created a new www.idestini.com to advertise my efforts. If you know a small business or organization looking for a new site or some updates to their existing site (especially from the Little Rock area), please forward them on over.

Displaying SharePoint Blog Posts In Your Team Site

I thought I had a simple problem. I wanted to display the blog posts from my team’s SharePoint blog site on my SharePoint team site’s front page. See, our blog site is a sub-site of our team site. You’d think that’d be as easy as pulling in a list web part and telling it which blog to display but noooo. That was such an interesting development experience that I have to recount it for you lovely developers out there. Here were the steps I had to complete.

  1. Turns out that first I had to go get a copy of Microsoft Office SharePoint Designer because you can’t do this through the admin screens. I opened it up to discover it looks a lot like Visual Studio products. Ok. 
  2. Next, you need to get your site opened up in SharePoint Designer. If you’re savy, you can do this right from SharePoint Designer by going to File > Open Site and entering the URL for your site. 
  3. In the tabs at the top of Designer, you’ll find a tab called Web Site. Find, the file you want to edit. In my case, I wanted to edit the Default.aspx of my team site. Before changing anything, I highly suggest you create a backup of the original by copying and pasting in that browser. After creating your backup, double click your file to open it.
  4. Ok, here’s the fun part. You need to create and connect a view for the page and a data connection to your blog site from your team site. To do this, select Data View > Insert Data View. Now, on the right side of the Designer, you’ll see a Data Source Library. Select Connect to Another Libary to bring up the Manage Library box. Give it a name like Blog and enter the URL for the site location of your blog and press Open. Press OK a bunch of times to get out. Now, at the bottom of the list, you should see your blog data source. Expand it and find SharePoint Lists > Posts. Press the drop down and select Show Data. You’re almost there. Now click and drag from the “Row” text at the top of the Data Source to the Data View within your page. You should see your post data.
  5. You can now click all the little arrow boxes to change layout, fields displayed, and so forth. You can drag more fields in from the right and customize headers and breaks as you please. Make sure you save a few times along the way as the designer may crash on you if you’re unlucky like me. When you’re done, just save one last time and go look at your page.

I’m not a real SharePoint developer by no means. I can work my way around the admin screens and create pages and sites, but geez, that’s an insane amount of work to display a little data (granted, slightly non-standard data) from a sub-site. I hope this helps you not experience as much frustration as I did!

Naming Internal Web Applications

Your company actually lets you develop applications for your internal employees. Awesome! You have a web server and you’re about ready to publish it. But what should you name your site? If you’re publishing to an existing portal that already has a name such as apps.mybusiness.com, what should you name your application’s relative location?

If you’ve tried searching online for a domain naming conventions or application naming conventions for internal applications, you probably came up pretty empty. Since there doesn’t appear to be much on this subject, I’ve decided to come up with a few suggested guidelines you may choose to follow when naming and publishing your internal web applications. In no particular order, here they are.

Select an appropriate home for your application.

In business, we end up having a lot of applications that we need to get to. There are customer management systems, HR systems, technology support management systems, time sheet systems, document management systems, and so forth. Ideally, your organization should have one portal that houses links to all internal applications. One portal to bind them all, so to speak. You can hide or show links based on access rights if you want, but have one place that tells everyone where to go for anything.Think of applications like families. Your applications don’t have to be physically hosted near each other, but they should appear related in the eyes of your users. The HR links should all be presented from the same user interface. The same goes for all of the operations support systems.

Select user-friendly URLs relative to your portals and applications.

If your organization is known as ABC Widgets and you have an internal application named Time Tracker, an example of a friendly URL is apps.abcwidgets.com/timetracker. The idea is that all of your internal applications would be accessed from apps.abcwidets.com. If possible, you would select a relative URL of timetracker for this application. Most of the time, it’s impossible to control URLs like this because of varying application platforms and legacy issues. Aim for creating one portal with all the links available in a way that makes sense to your users. Then, when you can control it, name your URLs according to something that describes what the purpose of the link is. Don’t use server names, state names, president names, Sesame street characters, or whatnot.

Don’t reengineer internet conventions.

Don’t institute your own domain suffixes. This means no abcwidgets.apps. Only use fully qualified domain names and don’t override existing URLs. That means, don’t institute your very own answers.com. Using a fully qualified domain names means you use something that could only be resolved to your resource according to the tree like hierachry of the web. Across the world, this is how people are interacting with the internet.

Lastly, please don’t drop the suffix from your URL. Most web browsers will try to resolve the entry even without a domain suffix, so if you name your application simply timetracker and your user isn’t connected to your network or can’t resolve the entry they are going to be really confused by what they see.

In closing…

Spend some time thinking about your domain naming scheme. Make it logical to a normal person (not the developer). Changing internet conventions is just confusing to users and silly. You can probably train your employees to remember what you’re doing, but why waste the effort? There are much more important things for them to remember and you’ll just create stress when they incorrectly enter your domain name. Keep it simple and conventional, please.

These are just suggestions. You may have a legitimate reason to do something different from this list. If you do, please share your experience with me. And, if you know of a good resource for best practices, conventions, or standards on domain names for internal applications, please share them.

Copyright © 2016, Abby Sims