Q and A

The main difference between XMLsitemaps and HTML sitemaps are that they are both more helpful, better depending on the purpose and who’s it for. XML sitemaps are more helpful to search engines, while HTML sitemaps are more helpful to humans and users, yet bots can still navigate HTML sitemaps fine.

HTML sitemaps are provided within the specified HTML, made with HTML code. They display all the available links so there is no investigating or hidden links whilst XML sitemaps, made with XML code, are defined in robots.txt or submitted in search consoles.

The links in a HTML sitemap are often organised by category whilst XML sitemaps contain metadata and urls.

The disadvantages of XML sitemaps are that there is no guarantee of indexing, meaning the search bots are not mandated to crawl, explore search and discover your entire website with all it’s internal links. There is also no link authority and it is completely useless to human visitors. However, benefits of a XML sitemap are how simple it is to put together, the format supports metadata so you can view when things were last modified, it also tells search engines of the available urls. Moreover, you can simply generate an XML sitemap with a plugin or free website these days.

The benefits of HTML sitemaps are that, due to it being available and visible on the html, it’s more user friendly and enables easier navigation. Therefore this is a pro for both bots and human visitors. Bots are now able to discover, “orphan” pages, a link with no internal links. The cons are that it is higher maintenance to upkeep, when new content or links are released there always needs to be adjustments. On sites containing many internal links, this can mean a very cluttered scene, which might make the practibility of this sitemap lose points. It also lacks search engine metadata.

Notepad++ is developed by Microsoft, it has been included with windows since 1985. It’s open sourced, written purely in C++, has little to not footprint and is less than 15 MB to install. This IDE edits plain text very well.

Adobe Dreamweaver was developed by Macromedia in 1997 and acquired by Adobe in 2005. It is both a code editor and a webkit, as you code you can view live the output within the workplace, (WYSIWYG, What You See Is What You Get.) Heavy desktop application packed with many feautures, however it’s very capable and powerful, which is what profressionals use and why.

Sublime Coding Environment was developed by Sublime HQ and released in 2008, it contains a plugin ecosystem and offers cross platofrm support, (adept on Mac, Windows, Linux.) As the name alludes, this IDE has a subliminal interface. While it’s minimal, it’s still very capable. There are distraction free-editing modes and easy navigation with, (Goto Anything.)

Very briefly notepad positives are it’s free, instant bootup, minimal footprint, simple, reliable. The negatives are how its outdated, not tool equipped, (syntax highlighting, code completion) and windows only.

Adobe Dreamweaver positives are it’s WYSIWYG live editing, visual editing, clearness, built-in FTP, Adobe ecosystem intergration, seamlessness, responsive layout tools, (simplify grid design and coding for advanced users.) The negatives are that it’s costly, heavy loaded application with a large footprint on your machine, outdated workflow, (you cannot drag to drop) no generated code suggestions.

Sublime Coding Environment is very fast, not much lagging freezing ever, operates identically across all platforms, instant commands and shortcuts features, highly customizable with a wide plugin ecosystem. Yet it’s still costly, requires manual adjustments and customization and has no built-in terminal.

How would each suit an entry level trainee code developer? Well Notepad++ would be poorly, it’s outdated, learning anything on notepad in the long run doesn’t help scale their profressional experience. Sublime Coding Environment is good, as it’s lightweight for entry level trainees to grasp and customizable. However it still requires manual setup for debugging and terminal interaction with plugins. Adobe Dreamweaver? Not reccommended. This is for experienced profressionals, it’s very heavy on not just the machine but on a newbie. Moreover, they may rely heavily on WYSIWYG where they code visually with dragging and dropping elements rather than by typing and thinking.

In 1990, Sir Time Berners-Lee created Nexus, “WorldWideWeb” the first ever web browser. Then 2 years later, 1992, MidasWWW was the first web browser with view source-code tool. Then the next year, NCSA Mosaic introduced image display with embedding accompanying text. In 1994, Netscape Navigator released an improved version that became very popular. But then, Microsoft launched Internet Explorer, triggering the First Browser War, (Microsoft won.) In 2003, safari was launched. Netscape fades in this era. Mobile safari is launched in 2007.

Some issues in the early days of development were the delayed adaption of W3C standards. Only until the early 200s were they being picked up. The browser wars made competitors release non-standard features to win over users, therefore this meant multiple required versions of one website for multiple browsers. Therefore browser compatibility wasn’t a given. It was difficult to keep loading speeds fast but keep the design modern. A lot of people ran outdated browsers so extra code had to be written for that.

There are many website testing methodologies, browser compatibility tests such as layout rendering which can be done with chromium based or webkit based browsers, manual cross-browser testing or BrowserStack or Sauce Labs to automatate this across many operating systems and browser combinations. Developers do this to see whether the website performs are intended accross a multitude of web-browsers and devices, firefox, windows edge, safari then iphone, android mobile runs.

Then there is website functionality tests, you can use E2E Automated testing to simulate your website, accessibility testing to test website compliance, (use validators like w3schools validator) performanceand load testing on Google Lighthouse for speed and site loading, Usability testing UX for site user-friendliness and flow.

Simply, the endorsed requirements of accessibility for all NT government webpages are in compliance and reference to WCAG 2.2. WCAG, (Web Content Accessbility Guidelines) 2.2 are a set of guidelines that ensure accessibility for users who visit websites.

Locally when organising assets for a specific webpage, it’s best to store it all in one folder. “my-webpage” for example. Then in that folder, the raw assets should be in a folder name “src”, (contains psd files or big projects) then a new file for index pages. Otherwise, skip this and immediately there be example.html, sitemap.xml, robots.txt. There will also be, “css”, “js” and, “images” folders, css for containing css stylesheets, js for javascript files and images for all images including .svg, .webp, .png, .jpg, etc.

However when uploading to the root folder of the website, uploading for the website, the best structure to have is immediately the examples.html file, alongisde potential others, robots.txt and sitemap.xml. Then there will be a css folder, js folder and images folder each to their own as iterated in the paraph previously.

In css folder there will only be .css stylesheets. In an images folder there may be .svgs and multiple image forms, multiple folders if there are many images. For example, “index-visuals” folder containing images for index.html, or “provided-imgs” containing categorised images a range of webpages may rely on. In javascript there shall only be javascript but further organisation is not discouraged if required.