How AI supercharges my web development: Building GpxFix in a week

Developing modern web applications has never been easier, thanks to AI-powered tools that accelerate coding, debugging, and learning. As a solo developer building GpxFix, a tool for editing and analyzing GPX files from fitness tracking and trail navigation apps, I’ve seen firsthand how AI assistants, smart IDEs, and open-source libraries drastically cut down development time while improving my skills.

In this post, I’ll share how ChatGPT, GitHub Copilot for Visual Studio and open source libraries like Chart.js, and Leaflet.js help me build faster, write cleaner code, and continuously learn, all while delivering a polished web app.

AI-powered coding: GitHub Copilot & ChatGPT

Instant code suggestions with GitHub Copilot

• Faster Development: GitHub Copilot (integrated into VS Code) suggests entire functions, API calls, and even complex logic in real-time. Example: When implementing GPX file parsing, Copilot auto-generated boilerplate code for XML parsing, saving me hours.
• Fewer Errors: It catches syntax mistakes and suggests optimizations, reducing debugging time.
• Code documentation: Auto generating comments means less typing.

Learning & problem-solving with free ChatGPT

• Debugging Assistant: When I hit a roadblock (e.g., a weird bug in Leaflet.js), ChatGPT explains the issue and suggests fixes.
• Learning New Concepts: Instead of sifting through docs, I ask ChatGPT for tailored explanations (e.g., "How does Chart.js tension work?").
• Generating Sample Code: Need a quick example of a dynamic Chart.js graph? ChatGPT provides a ready-to-use snippet.
• Refactoring: Easily recaftor, clean up and get suggestions for code optimization and performance improvements.

Ideas, design and content

• Feature ideas: AI chat tools help me come up with new feature ideas.
• Architecture: It helps to recommend architecture patterns.
• Content production: In this age of SEO you have to produce content to get traction.
• Business ideas: AI helped me come up with ideas for how to monetize the app.  
• Logo design: AI was used to design the logo.  

I tend to use a mix of Github Copilot, Google Gemini, ChatGPT and even Deepseek.
I typical have several threads or topics active in different AI tools in different browser windows. Using different AI tools in different windows makes it easier to jump between conversations as I can more easily identify which conversation is active in which browser window.
Although Github Copilot is increasingly getting better, it is still a bit slow as it takes the codebase into context and provides more integrated code.

Visual Studio + AI = A developer’s dream

• Intelligent Autocomplete: VS Code’s built-in IntelliSense + Copilot means less typing, more building. I keep getting surprised by how often it actually predicts exactly what I need. Holy **** it is reading my mind. I keep thinking.
• Git Integration: Auto generate GitHub commit messages, although this is also usually slow.

Result: A polished app in record time

Before AI, building GpxFix would have taken weeks. Now, with:
GitHub Copilot speeding up coding
ChatGPT explaining concepts
Chart.js & Leaflet.js open source for stunning visuals
Visual Studio streamlining everything
…I’ve built a fully functional, production ready web app with SEO, logging/alerting/monitoring and unit-tests in a week. I also managed to cram in competitor research and writing this blog post. Yes, I admit ChatGPT was also used to help craft parts of this page. 

Basically, AI is helping me at every single stage of the development process.

Final thoughts: AI isn’t replacing developers—It’s making us faster

AI tools don’t replace the need for coding skills, they enhance them. By automating repetitive tasks and accelerating learning, they let me focus on what matters: building a great product.

If you’re a developer and not using AI assistants yet, you’re missing out on the biggest productivity boost in decades. 

Vibe coding has become popular but for me as an experienced developer I want to keep learning and understand what is going on in my web app. I don't want to just tell the computer what to build and then constantly instruct the AI to redo and change stuff until it gets it right.

Try GpxFix here: www.gpxfix.eu

How are YOU using AI in development? Let me know in the comments!

How to rate internal product quality during systems development

There are many ways to define and rate product quality. This product quality rating is based on typical product quality assessments for software products and in particular online software.
This post was written for dev teams who do not have a dedicated QA manager or the like.

Why

So why should you do a product quality rating? It will give you an indication of how well the product is engineered in a more holistic perspective. Many will judge the quality of the product based on what end users say about the product. While end user feedback is a very important indicator of quality or value, the product may still have many issues underneath the covers that are just waiting to blow up and become a big issue for the user or other sides of the business.

This product quality review helps to get a complete overview of the product and its strengths and weaknesses. It helps to plan ahead and reduce risk.

How

The rating can be conducted by the product development team, perhaps in collaboration with others such as internal users and other stakeholders. As several of these categories are only known to the dev-team this rating cannot be done by customers or other external stakeholders.

A score from 0 to 10 can be given where 10 would be the score that the best product on the market would receive in that category.

Extensibility

Is the product considered to be extensible? Can it be enhanced with new capabilities or functionalities without hampering its existing functions?

Availability

Is it product ready for immediate use? Does it require a lot of configuration including technical setup? Is it difficult to get started with the product? Are there long start-up times?

Features

Features are the “bells and whistles” of products. How complete is the product? Compared to competitors how would you rate the feature-set in terms of user value? Are you missing important features? Are there many half-finished features?

Performance

Refers to throughput and latency. Can the system handle the user load? Is the system perceived as slow at times?

Accessibility

Is the system accessible for impaired/handicapped users?

Reliability

Does the product perform flawlessly under stated conditions for a long period of time?

Correctness / Conformance

Is it free from faults/bugs? Is it aligned with specifications? Does it conform to standards?

Efficiency

Does the product perform effectively without wasting resources?

Maintainability

Is it easy to maintain code?

Understandability

Is it easy to understand and grasp what the product is for? Does it seem too complex?

Usability

Is it easy to use and learn?

Supportability

Is it well documented? Is it easy to support?

Scalability

Does the product scale well and can it handle controlled increased load? Is it efficient when new resources are added?

Robustness

Is the product able to withstand harsh conditions and rough handling? It should be durable enough to endure erratic variations in stress as well as pressure that too with minimal damage or alteration to its functionality. Does it handle bad or corrupt data?

Security

Are there any likelihood of potential security breaches due to poor coding practices and architecture etc? Have you done penetration test or security audits? Do you have logging, exception handling etc.

Elegance

Is the product stylish, good looking, giving a good first impression?

Further reading

http://sloanreview.mit.edu/article/what-does-product-quality-really-mean/

Fluid, Responsive and Adaptive VS Fixed layout

In this blog post I present a way to decide on Fluid, Responsive and Adaptive VS Fixed layout. I have chosen to bulk Fluid, Responsive and Adaptive together because they are similar in that they adjust to the screen size, fixed layout does not. Fluid, Responsive and Adaptive layout are all different but for brevity I will call them Responsive below.

Most old websites have a fixed layout so many developers who are in the situation of giving a facelift to a legacy website often have to decide between Responsive VS Fixed layout.

The rise of Bootstrap and responsive layout with its extremely easy to use framework has certainly contributed to a many developers dropping their fixed layout.

I have observed how many web developers have just jumped on the bandwagon and adopted Bootstrap because it is just so darn easy. As an engineer I feel that many blindly go for Bootstrap or similar framework without much thought.
So below I give a more nuanced look into what to consider before redesigning an existing web application. The factors below have been picked especially for rich interactive social web applications rather than simple informational public homepages. I also assume you don't have unlimited resources so you are, as the rest of us, constrained to a limited development time.

Factors to consider

A - Esthetics.
B - Speed of user interaction.
C - Accessibility/ease of use.
D - Development time.
E - Screen size of users.
F - User browser maximized or not.
G - Mobile support.

All projects are different so you have to decide which of these factors are more important to you.

A: Do you want our application to look perfect with less cost? 
It is easier to make the site look good with fixed layout because layout often breaks with fluid layout. Images that users add to content areas don’t wrap as they expect on other screens. Headings added by users don’t wrap how they like on other computers. Background images can look weird etc.
If you have few resources and you want the app to look really good (on PC) you might want to steer towards fixed layout.

B: Do you have super users? 
How are users using the app? Are there mostly highly drilled users? Is it a Line of Business app where the business will measure the time users spend doing their work in the app? Do users have to be able to complete their tasks really quick?
By using more screen real estate users can perform actions faster and find information faster without having to scroll, use paging or navigate.
If you have requirements for being able to do lots of actions fast you may want to steer towards responsive layout since you are able to use more of the screen width.

C: Do you have to be particularly user friendly? 
Using more screen real estate will often lead to more “things” being visible on the screen. More things = higher cognitive load. For super users this is fine but for users who is not using the solution that often and for senior users this will reduce their user experience because they are simply overwhelmed by the content and options visible.
So who are you targeting? old people, beginners, non-computer literates.
Responsive design does not have to increase the amount of stuff on the screen but it usually does. A fixed layout is easier to learn as it always looks the same. If you by any chance did not maximize the browser window as you usually do you might get a different view than you are used to. For computer illiterate and infrequent users this can pose an issue. With a mobile first design approach, a max width and adaptive layout the UI can still look clean but this is not compatible with B above.
If you have requirements for being very user friendly you may want to steer towards fixed layout.

D: How much time do you have?
My initial starting point for this blog post was that you were about to decide to change from fixed to responsive layout so naturally you are in for more work if you decide to change. Also responsive layout requires more development and testing to check that it looks good on different screen sizes.
If you have little time you may want to steer towards fixed layout.

E: What's the typical screen size of your users?
If a significant percentage is using a screen that is smaller than the fixed layout width or they are using phones and tablets then you should definitely switch to responsive.  If users are having a screen size that is smaller than our fixed layout it will cause bad horizontal scroll bars or zooming that makes it very cumbersome to hit buttons etc.

F: Do users have their browser maximized? 
Could for example be because users need to keep multiple windows side by side etc for example when they need to copy content from another window and into the app.
In this case a responsive layout may work better.

G: Do you have to support mobile?
This is usually the one biggest concern that will decide it all. Is it a strategic goal that the app work well on mobile? Do you have plans to develop a separate mobile web app or even native mobile app? For many it is just too resource demanding to develop a separate mobile/native app so in this case you would go with responsive layout.

What are others using 

(Note that it is usually not a black or white choice. Most sites use a mix of techniques for example facebook is fixed but uses some adaptive techniques such as the chat and contacts feature on the right side)

Fluid/Adaptive/Responsive layout:

• SharePoint
• Jira (Confluence)

Fixed layout:

• LinkedIn
• Facebook
• Yammer
• Podio

Side note

Why does Wikipedia have fluid layout? Because all you do there is read articles. Ease of reading is extremely important there. With fluid layout the user has full control of the readability (line length etc) by resizing the browser window and adjusting browser font size.

Further reading

• http://ux.stackexchange.com/questions/21/for-websites-is-it-better-to-have-a-variable-width-layout-or-a-fixed-width-layo
• http://www.smashingmagazine.com/2012/11/08/ux-design-qa-with-christian-holst/
• http://www.quora.com/Why-doesnt-Wikipedia-use-fixed-widths-for-layout

40 most funny code comments ever

These are borrowed from
http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered and http://www.quora.com/Computer-Programming/What-are-some-of-the-funniest-comments-in-source-code

Exception up = new Exception("Something is really wrong.");
throw up;  //ha ha



//When I wrote this, only God and I understood what I was doing
//Now, God only knows 

stop(); // Hammertime!

// sometimes I believe compiler ignores all my comments

// I dedicate all this code, all my work, to my wife, Darlene, who will 
// have to support me and our three children and the dog once it gets 
// released into the public.
 

// somedev1 -  6/7/02 Adding temporary tracking of Login screen
// somedev2 -  5/22/07 Temporary my ass

// drunk, fix later
 

// Magic. Do not touch.
 

#define TRUE FALSE
 

//Happy debugging suckers

// I'm sorry.

return 1; # returns 1

Catch (Exception e) {
 //who cares?
} 

/*
 * You may think you know what the following code does.
 * But you dont. Trust me.
 * Fiddle with it, and youll spend many a sleepless
 * night cursing the moment you thought youd be clever
 * enough to "optimize" the code below.
 * Now close this file and go play with something else.
 */ 
 

try {

} finally { // should never happen 
} 

const int TEN=10; // As if the value of 10 will fluctuate... 
 

//This code sucks, you know it and I know it.  
 

//Move on and call me an idiot later.

double penetration; // ouch, no cumments needed
 

/////////////////////////////////////// this is a well commented line

// I don't know why I need this, but it stops the people being upside-down 

x = -x;
  

// I am not sure if we need this, but too scared to delete. 

doRun.run();  // ... "a doo run run".

# To understand recursion, see the bottom of this file 
At the bottom of the file:

# To understand recursion, see the top of this file

// I am not responsible of this code.
 

// They made me write it, against my will.

/* I did this the other way */
 

/* Please work */

// no comments for you
 

// it was hard to write
// so it should be hard to read



options.BatchSize = 300; //Madness? THIS IS SPARTA!

// I have to find a better job

# code below replaces code above - any problems?
# yeah, it doesn't fucking work.



class Act //That's me!!!
{

  ...
}

public boolean isDirty() {
    //Why do you always go out and
    return dirty;
}



Repeat
    ...
Until (JesusChristsReturn) ' Not sure



// Catching exceptions is for communists



// If this code works, it was written by Paul DiLascia. If not, I don't know
// who wrote it



//this formula is right, work out the math yourself if you don't believe me



// Comment this later
  

/** Logger */
private Logger logger = Logger.getLogger();



// Remove this if you wanna be fired



# This is becoz you messed with me the other day
if current_admin.name == "#{my_x_employer}"
  sleep(1000 * 3600)
end



# Linux Sex
$ date ; unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep



// Peter wrote this, nobody knows what it does, don't change it!

}catch(Exception ex){

   // Houston, we have a problem

}

// If I from the future read this I’ll back in time and kill myself.

// TODO: I believe the method (and all class in general)
// doesn’t make any sense at all, but I’m sleepy and
// it works fine

// A function that retrieves all females from the database
// for processing and display:
function getGirls() { //if only it were really that simple

float boat;   // must be a float, otherwise it sinks.

// I can’t divide with zero, so I have to divide with something very similar 
result = number / 0.00000000000001.

// no comments for you
// it was hard to write
// so it should be hard to read

A simple requirements specification template for websites

If you are about to develop or hire someone to develop a new website you will need to articulate a set of requirements or needs for your coming website. In this blog post I will present a simple check list / template that can be used as a starting point. For more advanced high end sites you should go with a more in-depth process but the questions below might help you get started.

Visitor features

What should the visitors be able to do on this website? What kind of user interactions will the site have? Most importantly answer why. This should all be defined based on a content strategy / information strategy etc. What about multi-language support on content and the editor interface? What about features such as: contacts, events, press releases, product catalogue, webshop, automatic creation of PDF's such as reports, image gallery, videos, FAQ, user comments, forum, blog, wiki. Will there be specific needs concerning advanced content and design such as storytelling, copywriting, art direction etc.

Administration features

How will the website content be updated? Will there be any particular process for adding and modifying content? How many persons will be doing it, how often? How computer literate is this person who will be updating the content? Will you need to manage an online community associated with the website? In that case you might need a community manager, moderator etc.

Future site upgrades

Is it important that future developments to the site can be done by most development shops/consultants? If so state a requirement to use a commonly known CMS. Do we need any service level agreements for system changes to the site? Do we need support for the content editors? Do we need technical documentation on how the site is built? If there is a lot of advanced customization this might be a good idea.

Scalability

Is it highly likely that the site will become very popular within a few years? If so consider SaaS, PaaS, cloud services etc. to help you cope with dynamic traffic demands. This is also relevant if you know the site will have extreme traffic spikes at specific times of the year.

Site structure and content

Create a hierarchical view of the pages that will be part of the site. This can simply be a document with level headings going from heading 1 to 4. You probably also want to provide multiple ways to your content by using tags or categories? Will there be user generated content and what is the extent? Will there be massive amounts of content? What is your unique selling proposition (USP)? How will your site stand out?

Logging and audit trail

Is it important to log things like who did what when with site content?

Key Performance Indicators 

Will the persons responsible for the website be followed up on KPI's? E.g. maybe the web team is required to create a new post each week? or maybe there is a requirement that the site should have a certain number of visitors or be on a list of top sites within a specific category?

Visitor tracking and reporting

You probably need to visitor statistics. Is Google Analytics fine?

Search Engine Optimization (SEO)

How high are our ambitions when it comes to being found on and ranked high on search engines?

Accessibility

Should people with special needs be able to use the site? How much support should they get? Should they just be able to read it or should you provide good user experience for this group? Should blind people be able to use the site?
Where should the site be available? What kind of devices? Old devices/browsers?

Style

What kind of look, mood, style do we want? How do want to be perceived? Our values and mission has to fit the style. What level of design excellence should we strive for? Is it important that the readers find the site really good looking and appealing?

Security

Do we need special considerations when it comes to security and permission control? Will different people need different access to some content? Will some editors need more permissions than others?
Is it extremely important that the site is not hacked? Hackers typically break site and put advertising and malware on hacked websites.

Speed

Is it important that the site is fast to load? Do we need the site to scale? will there be millions of visitors and will the traffic grow?

Server location

What about hosting? How will the website be hosted? In your country? Maybe you have compliance rules to follow when it comes to where the server is located? Do we have environmental concerns? Some hosting providers are more environmental than others. If most of your users come from the other side of the world then consider a server location in that region.

Stability

Is it important that the site is available at specific times. Do we need disaster recovery and service continuity? Extra redundancy and backup plans in case of atomic bombs wiping out your country? a bit extreme there but you get the point.

Other requirements 

Non functional and functional? Maybe we are required to use Open Source? Will there be a need for related services such as video editing, brand/identity design, design of advertisement banners. What about e-mail accounts?

Contract 

Escrow? Budget? Time plan? Legal issues?

Complex web pages have huge differences in rendering time in different browsers

I recently had the task of optimizing HTML for a web application that was getting somewhat slow. We were seeing big differences between browsers. Chrome seemed to be exceptionally fast. So I went ahead trying to reproduce this performance issue in order to decide where to go ahead with optimization. 

I knew that the web app had lots of nested divs with a lot of inline styling. I was curious to find out what performance penalties this had so I made this client side performance test.

There's a lot of websites that talk about website optimization and they all say you should minimize the payload that has to go over the wire. I could not find much on the topic of speed when it comes to rendering large HTML documents.

Summary of results

My tests show that large DOMs with many nested elements (in this case 7381 divs) can have a huge impact on client side performance. Compared to Chrome, IE9 spent 9-25 times longer rendering the exact same page.

The tests

I programmatically created 3 html documents; A, B and C. They all have nested divs and some styling. They look something like the grid below. It has 1 big square and inside this square there are 9 squares and inside this there are 9 squares and so on. It goes 4 levels deep so there's a total of 7381 divs. Fairly simple HTML document but the DOM is relatively big.

Measurements where done using the HTML documents that are linked to blow. The server was located in the same country and the Internet connection where this was carried out was very good. The browser cache was unprimed. All the divs have fixed size so drawing the layout is pretty easy for the browser. There is no need to recalculate and re-position elements as the page is gradually received.

Test A 
This document has lots of duplicate inline styles just to create lots of bytesize. Each div looks something like this:

<div id="d_34" style="width:34px; height:34px; float:left; dispaly:block; margin:0; padding:0; border:1px solid #FFFFFF; background-color:#bbb">...

Test A document size is 1.1Mb

	IE9	Chrome19	FF13
Typical time until received all bytes	390ms	330ms	339ms
Typical time until DomContentLoaded event fired	2,22s	411ms	1,33s
Typical time until OnLoad event fired	2,43s	408ms	1,34s
Time from all all bytes received to onLoad and DomContentLoaded event fired	2040ms	81ms	1001ms

Test B 
This is just the same as A only with all the inline styles moved out to an external css file. Now each div looks like this:

<id="d_34" class="lvl2">...

Test B document size is 237Kb with an additional 400b CSS file.

	IE9	Chrome19	FF13
Typical time until received all bytes	187ms	178ms	195ms
Typical time until DomContentLoaded event fired	1,02s	227ms	366ms
Typical time until OnLoad event fired	1,18s	210ms	457ms
Time from all all bytes received to onLoad and DomContentLoaded event fired	993ms	49ms	262ms

Test C
This is without any styling at all. Each div looks like this:

<id="d_14">... 

Test C document size is 179Kb.

	IE9	Chrome19	FF13
Typical time until received all bytes	172ms	130ms	160ms
Typical time until DomContentLoaded event fired	468ms	175ms	170ms
Typical time until OnLoad event fired	590ms	140ms	253ms
Time from all all bytes received to onLoad and DomContentLoaded event fired	418ms	45ms	93ms

What does all this mean anyway
From the numbers we see that when it comes to comparing browsers, Chrome outperforms the others. IE seems extremely slow when it comes to rendering this particular markup. Although IE9 is credited for being much faster than earlier versions, it is clearly far behind Chrome for this specific test.

Chrome is particularly fast when it comes to rendering. It only uses about 50ms to render the page which consists of more than 7000 elements. Chrome is faster for all cases (with inline styles, with external css file or even without any styling at all).

The test also confirms that avoiding inline styles on elements will increase performance considerably. The reason seem to be not just that there is fewer bytes to transfer but that it is easier for the browser to parse the document.

Please note that our test is not representative for common web pages or for other web pages for that matter. Browsers use different algorithms and techniques for different operations such as receiving, parsing, calculating layout, drawing etc.

50 reasons why I don't like SharePoint development

I was introduced to SharePoint in 2001 when it was called SharePoint Portal Server 2001, codename Tahoe. From time to time I have been put on SharePoint projects but I never came to like it.

I think I have worked on more than 10 SharePoint projects, some of them fairly big. The last time I used SharePoint was back in 2011 with SharePoint 2010.

This blog post is not intended as an evaluation of SharePoint with a socio-technical economic corporate or whatever perspective. SharePoint might, or might not, be a good choice for your development project. This post is Not about SharePoint as a viable product. This post is solely about what I think about SharePoint as a development platform.

Please note that I am talking from my experience as a developer who happen to like simplicity, structure and who cares about usability. What you will find here is simply my personal view of SharePoint development. This is based on doing deep custom SharePoint development, not just configuring out-of-the-box SharePoint sites. Also note that this blog post was written before the release of SharePoint 2013.

Not just me being an old crank
Even prominent people within the .Net community such as Carl Franklin and Richard Campbell openly say what they think of SharePoint. In .Net rocks podcast episode 734 Richard Campbell makes the following joke: "The thing about SharePoint is you start on having a problem you think you can solve with SharePoint and then you have two problems."

Richard Campbell even goes as far as to say SharePoint makes you cry.

You'll even find developers of SharePoint at Microsoft out right saying: "It is not, and never will be, a viable developer platform."

The 50 reasons why I don't like SharePoint development and why I'll hopefully never do any more of it:

1. SharePoint kills creativity with its configurations. Flicking on xml/xsl files is not very inspiring.
2. The backend user interface is mostly not very intuitive. I as a developer don't like to develop systems that suck.
3. SharePoint as a framework is too big and complex and you never get to feel that you master it all.
4. The product is pricy and too big so I can't use it for my private projects. That means I will not be able to reuse the skills on my hobby projects.
5. SharePoint experience has limited transfer value for other type of development projects. 
6. There is usually IT politics involved since it's a big decision to start building the competence and infrastructure. With politics often follow dirty games, power struggles etc.
7. SharePoint requires lots of training and long-lasting changes in the behaviour of users. This means that you don't get to see the results of your work and how users actually end up using the system. By the time the use of the solution has stabilized you are long gone on other clients, other projects or have left the firm.
8. Once an organization and the development team has acquired SharePoint licences and competency they tend to reuse SharePoint on other IT projects where SharePoint is not the best fit. SharePoint often becomes overkill and results in very large development costs. You as the developer may end up having developed a system that is doomed to fail. 
9. Organizations who have acquired SharePoint for their internal systems often want to reuse the platform for their public facing website to consolidate their infrastructure/licenses. It brings with it a large overhead and the public facing website becomes too complex to manage , maintain and evolve. You as a developer might get stuck doing boring support or very difficult maintenence.
10. Agile methods can become problematic. SharePoint content types cannot easily be changed once it's in production or even in testing environments. This means projects have to be fairly waterfallish.
11. Difficult to write unit tests. Poor separation of concerns.
12. SharePoint version 2010 does not support .Net framework 4.0.
13. The platform is resource demanding and becomes slow on your dev machine, especially if you have a VM setup.
14. Debugging is slow. Timeout occurs. When attaching the debugging you'll often hook on the wrong w3wp.exe.
15. Poor HTML rendered. Takes LOTS of time to customize rendering.
16. No Asp.Net MVC support (unless you are only using the SharePoint API) .
17. Heavy frontend html/js/css that runs slowly in the browser.
18. Lots of XSL files. I never liked XSLT.
19. Making control adapters is a headache, must deploy but then reactivate web app feature to deploy app_browsers file. compat.browser with control adapters debugging often don't work.
20. The ghosted/unghosted feature of content types is a big headache.
21. Some super users will have the rights to change contenttypes, delete site columns, delete or move lists. This is dangerous if you have custom backend code that uses these lists.
22. Very difficult to investigate content in the database when debugging.
23. Often you do not need workflow, content approval and document versioning etc. All these things make the solution more complex and you will have to remove or deactivate these things if you don't need them. Scripting removal/deactivation takes time.
24. Lots of things happening under the hood that is not documented very well. New developers, not familiar with SharePoint will often make bad choices that will be very hard to fix later.
25. SharePoint requires a lot of competency so you often have persons specializing i various SharePoint fields and often you'll have parts of the IT department that do SharePoint maintenance/operations tasks. This creates dependencies between people and you often get stuck waiting for other persons or departments to deploy or do other development tasks. If the required person or department is unavailable you are of course stuck and you look bad.
26. Memory leaks are easy to add (although there are tools to find them), App pools regularly crash.
27. Packaging and deployment is of course different from anything else. Additional competencies needed.
28. The sheer magnitude of the product is difficult for developers. You'll need different third party tools. All the knowledge required is overwhelming.
29. When the site goes down or suddenly become slow after an upgrade it is often very difficult to pin-point the error.
30. The log file (ULS) is always filled with a ton of entries and you have no idea what half of them are. The ULS log is typically 2000 lines long and the error messages are very bad.
31. The API returns data that are concatenated and needs to be parsed.
32. Has to run on Windows server. It can run on Windows 7 but not really straight forward to configure your local environment if your team has a good continuous integration setup.
33. Unpredictable system performance. When you have performance problems and investigate you will often not find the problem because there are just too many moving parts. Suddenly the performance is better. You look at automatic database tuning, at changes in content and changes settings/configurations. You look for memory leaks, do performance testing in the testing environment, restore different versions of the production database, you look at visitor statistics, web server logs, sql logs, application event logs, ULS logs, look at timer jobs, various manual jobs that can have been started, you look at users behaviour during the period, you check automated response testing like Gomez, what's hitting your site, crawlers, what content is being read, when is backup and indexing on the database running. Has the MOSS search crawler been running etc but the problem is often a mix of interrelated issues so it's hard to find by investigating sub systems one after the other.
34. SharePoint has too many configuration options. An example is regional settings on each site. You might get problems showing dates consistently and not understand why.
35. Lots of access control and post release configuration required. You'll have to determine what content types, site templates, page layouts, webparts should be allowed to use by who and where.
36. If you on a page want to hide fields that are empty or add some conditional formatting you'll have to create custom webparts or usercontrols. Webparts that should be hidden in special scenarios requires additional development.
37. Some out-of-the-box webparts (such as search) creates poor html which makes them harder to style and look a like on different browsers.
38. Since everything is customizable in SharePoint you end up with less user friendly dialogs. For example if you use a very simple page publishing workflow there are still going to be superfluous user interface elements and interactions that makes it messy for the user.
39. Ambiguous error messages.
40. In a script-it-all dev environment you often configure some part of the SharePoint solution and to test it you do a deploy of the entire site by building it from scratch or running some upgrade scripts. You find that the configuration you just wrote did not work for some reason. The scripts takes 20 minutes to run so you spend the rest of the day tweeking the configuration files to get it to work by running the deployment scripts over and over.
41. Setting up a sitedefinition always seems to be a problem. Settings up a new sitedefinition and configuring what features, page layouts, content types, master pages, welcome page should be used for a site seems like a straight forward job. But this for some reason always fails and you have to modify the configuration and redeploy and redeploy and redeploy until you get it right.
42. A single typo in a setup config file can destroy your site and will be hard to locate.
43. You are using a very large platform and you can't just copy one installation to a new site and start from there.
44. In most cases you will start by reconfiguring the site from scratch. So most of what you do is to write code or configurations to build and deploy your site instead of spending time developing cool features using cool code.
45. It is difficult to script everything. There are simply to many customizations and configurations that can be done. There is always some manual change that someone forgot to script.
46. Too many layers of development. In other projects you might just have to copy the entire site, make some adjustments in a few config files, then set up the database and you are good to go. But with SharePoint you will have to write code that builds the things that builds your solution (unless you are doing simple projects using the SharePoint designer).
47. The whole development process tends to get messy because things are just hard and complicated with SharePoint.
48. Creating Internet facing websites are difficult because the platform has a lot of overhead. Lots of effort to go around things, removing things and making the site more accessible and faster.
49. Because SharePoint development is so complex things very often takes more time than estimated so you miss deadlines or have to work overtime.
50. If you have a SharePoint project with high expectations on visual design, usability or accessibility then you will require designers with good knowledge of SharePoint. This can be hard to come by and/or will require excellent collaboration between developers and designers. Often challenging.
51. Microsoft usually makes big changes to SharePoint with each new version. If you have not followed best practices you are in for lots of work if you are upgrading in the future. What the best practices are takes time to learn.
52. The preferred way to store data in SharePoint is with SharePoint lists. If you do not use lists and instead go with separate databases you can end up with a fragmented solution with many databases (SharePoint warranty breach if you meddle with the internal SharePoint databases). If you use SharePoint lists you are likely to run in to issues with the abstraction layers and problems trying to put relational data in lists.

Further reading

http://www.cmswire.com/cms/information-management/the-art-of-sharepoint-success-10-reasons-why-sharepoint-projects-fail-012592.php
http://codebetter.com/jefferypalermo/2007/09/13/sharepoint-is-not-a-good-development-platform

Native App or Web App for Mobile?

Ok so here's yet another web page on the Native App vs. HTML debate.
Too often I see people making snap decisions without a thorough analysis. So here's another of my blog posts where I attempt to cover all the various factors that should be considered when choosing between a native App or a web based mobile site.
This was written for organisations that don't want to spend the money or time to develop both mobile web apps and native apps. You can of course make both native app and a html web app or mix the two using hybrid approaches such as Phone Gap etc. You can also make dedicated web apps for dedicated platforms.

In the listing below I assume you or your organisations have some experience with web development and you are just considering a native app vs. a general web app. You already have a website designed for desktop.

When to go for a Native App

• Users use the app many times a day and need a fast way to start or switch to the app.   
• You have very high requirements on performance.
• You have high requirements on usability.
• Your app needs access to device specific hardware and API's such as notifications, calendar, volume controls etc.
• You are willing to lose some users (unless you develop both html and native apps for iPhone, Android, Windows, Blackberry etc).
• Your app doesn't need to or should not connect to the Internet.
• You want to learn Objective-C or other native app programming languages.  
• Your business model fits well with the monetization model of the App Store, Android market etc. It may be easier to make money off native apps (people tend to pay for apps because it is convenient. It requires close to zero effort to buy an App)   
• You want yet another channel to be found. (e.g. App store) 
• You want to use the App in marketing. (Apps are more cool. Few people talk about mobile web apps. People talk about Apps.)
• You don't want the clutter that comes with a browser (such as the address and navigation bar).
• Native Apps usually work better or feel more stable when the Internet connection is poor. (E.g. when you are on the subway)
• You need to hide your code from other developers. (You can't rip html, js and css from a native app)
• A native app is usually more secure. (Less data traffic. Less chance of phishing attacks and exposing sensitive information)
• You have content you do not want to be copied or ripped.  

When to choose a HTML Web App

• You need to push updates for the web app often and promptly (AppStore has a slow process)
• You don't know who your users are and what devices they will be using.  
• Your users are coming from random places on the web.
• You provide links to other websites. (navigation will feel more natural not having to jump in and out of web and native apps)
• You don't know who is going to maintain the app. (If someone else is going to further develop it there is a bigger change that you find the required competence if you go with HTML) 
• You already have extensive web development knowledge.
• You want custom design and branding. (On the web you can make it look however you like)
• You want complete control of monetisation, including advertising.
• You want to save time by reusing code between various web apps or projects and by reusing open source code and widgets such as sharing buttons, disqus etc.
• You want the app to have a long life span. (You don't know what kind of devices and platforms will replace the current. You can be certain that the web will be around for many many years)   
• You don't want to spend the money (time) to learn and invest in native apps development. 
• There will be few users. (Little point investing in a new development environment if the App will have only 20 users)
• A web app can more easily be used by the disabled (unless you develop a specialized native app targeted towards the disabled) 
• You want better analytics.
• Faster time to market. You don't have time to wait until you have the capability to develop a native app (it might require learning, developing server integration. A web app can often be made with very little effort and can naturally evolve if you have more time later or find that the web app gets popular).
• You know that a considerable number of users might not have mobiles that support native apps but might have older web browsers on their phones.  
• You want to support the development of the free open accessible non-proprietary web.
• You don't like the political or socio-economic ramifications of walled gardens such as the App store. 

This blog post was written in March 2012. If you are reading this in the future chances are that Web Apps have caught up with Native Apps one many of the their strong points because of HTML5.

Checklist before launching a website

If you are developing a small website for a hobby project or similar you might not have test scripts or a test plan. Here's a simple check list you can use for testing your site.

Design / Sign off

• All relevant persons/stakeholders have been given the chance to comment on the design.
• Relevant persons understand the concept/point of the site.
• Someone other than you can use the site with ease.
• Design has been tested on old projector with poor contrast. (There are tools to do this also)

Features

• All pages have valid title and meta tags.
• Other typical SEO guidelines.
• 404 page.
• Internal Server Error page.
• Content can be printed? (Print style sheet).
• Meta tags.
• Fav icon.
• Semantic Html
• Added analytics. Website visitor tracking statistics. E.g. Google analytics.
• Site map.
• Friendly URLs
• Form validation.
• Mobile support.
• Share buttons: Twitter, facebook, LinkedIn etc.
• Contact form works.
• humans.txt

Performance

• Yslow.
• Stess test.
• Pages checked for page size. Page footprint of more than 1Mb is bad.
• Caching evaluate. (Page output caching, data caching etc, web server caching, E-tags etc)
• Log been checked for errors.
• Home page downloads within 10 seconds or less.

Stability / accessibility

• Tested in all relevant browsers such as IE, Chrome, Firefox, Safari, Opera on different OS and with different versions?
• Site tested without JS enabled in the browser.
• Tested with various screen resolutions both small and large.
• Site tested with W3C CSS validator.
• Site tested with different screen resolutions and on iPad.
• Site tested on mobile.
• Site tested using accessibility toolbar etc.
• Site tested with full JS error notification turned on.
• Do you know your monthly bandwidth limit? Make sure your site resources are not to big and visited by to many people.
• All assemblies checked for memory leaks.

Security

• Backup.
• Robots file.
• System been evaluated against security threats.
• OWASP guidelines evaluated.
• Need to set up e-mail or SMS alerts? (There are monitoring services you can buy)
• ASafaaWeb security analyzer

Content

• Content placed consistently.
• Tense/Style of writing consistent.
• Dead links check.
• No empty pages.
• No Lorem Ipsum pages.
• Pages spellchecked.
• Content formatting consistent.
• Alt text on images.
• You have contact info, privacy, feedback, terms and copyright info.
• Site tested with realistic content.
• Site checked for missing resources (404 on images , js, etc.).

Content publishing related editor support

• Nested lists.
• Links.
• Images in text.
• Other text formatting.

Why not use Flash/Silverlight on public websites

This blog post is about why not to use Flash/Silverlight on your website. You can find hundreds of people who have already written on this topic but I still meet people who think it is a good idea. There are a few cases where it makes sense to use these technologies but in most cases you, your customer(s) and your end users are better off, not using Flash or Silverlight.

Why not use Flash/Silverlight

1. A page with Flash/Silverlight will load slower. Especially if the page also has a lot of javascript on it.
2. Inconsistencies with web standards. A flash movie gives a different feeling than ordinary web content:
   
   • Print does not work the same.
   • Copying content might not work.
   • Navigation, including back button don't work as you are used to.
   • Enlarging text doesn't always work the same.
   • Input fields, buttons etc look different and can confuse end users.
   • Bookmarking or linking to your site is more difficult since you're probably not able to link to the exact section within the Flash/Silverlight movie.
   • Searching text on the page (ctrl+F) doesn't work.
   • Less usable for the disabled.
3. Internationalization and localization is more complicated.
4. SEO is more difficult and in most cases will be less good than a plain HTML solution.
5. It is more difficult to maintain the code as the resulting .swf/.xap file is closed and require special skills other than regular web development skills.
6. Flash design is usually hard coded. You can not easily reapply a new style with such as with CSS. Silverlight makes this easier with XAML but XAML again requires knowledge and special tools.
7. It is usually more difficult to update Flash/Silverlight content. There's usually no wysiwyg support.
8. Q.A. gets more difficult (automated testing and code review is more difficult because it requires other skills and tools).
9. Analytics using tools such as Google Analytics is more difficult and usually less precise.
10. In most cases you don't have control over if the end user has Flash/Silverlight installed. Even if the website is an Intranet and everyone is supposed to have the same setup there's usually someone with a non-standard client that will complain.  
11. Flash will not run at all platforms. (e.g. Flash on iOS)
12. Flash/Silverlight is more difficult when it comes to progressive rendering. Normal web pages load and render parts of the page before the entire page with all the page resources are sent over the wire. With Flash/SilverLight you might need to create pre-loaders or put extra work into the implementation to make it load smoothly.
13. You might have to create fall back solutions for those who have not installed the Flash/Silverlight plugin.
14. Flash/Silverlight usually requires more bandwidth.
15. Some developers and designers will get tempted to put fancy features or overly fancy designs into the Flash/Silverlight and they often do. These features can often become a source of irritation as they waste the time of the user or make the user think. Often they will create fancy animations on their top notch Mac computers and forget to test it on slower computers. Heavy use of animations requires more CPU usage which again is less environmentally friendly.
16. As a developer you can get problems with stacking order if you have layers that will popup over the Flash movie. The Flash will always position it self on top, regardless of z-index. might work. Often you don't get into this problem until long after the Flash is developed and you need to update the Flash to fix the problem.  

Now that the web is getting more ubiquitous with mobiles and more and more client types appear (like tablet computers) it gets more important to adhere to standards and reuse best practices.

References:

• Jakob Nielsen's Alertbox, October 29, 2000: Flash: 99% bad