History

All users want their Internet site to be rich in content, elegant in appearance and well-structured — Munjari makes it possible.

The Internet is vast and contains a tremendous amount of material; the major search engines index billions of pages. A large part of this content-explosion has occurred in the last decade, which brings two questions to mind:

How did all this content get on the Internet?
Who put it there?

Bringing Content Online

As would be expected, Internet content creation tools have increased in sophistication over the years. They've developed from simple text publication systems to full-blown development environments capable of generating front ends for databases.

Though the target market changes, most of these technologies have been — and still are — out of reach for the average user.

The Humble Text Editor

At the dawn of the modern Internet, the majority of content was produced with a simple text editor. Authors wrote HTML by hand and uploaded to the Internet via FTP. It was generally a painstaking process and participation involved a lot of time, patience and experience.

Larger sites were generally only created by corporations, which had the resources — both time and money — to maintain them with the primitive tools available.

There were no tools available for interactive or generated web sites at this time — everything was created from scratch. The average user at this time was technical and today's "average" user was not yet "on" the Internet.

Site Builders

As a way of helping the average user get online, ISPs put a web-based front-end on their FTP servers in the form of a "Site Builder". This allowed users to more easily upload content to and removed the onus of setting up and registering a server.

Though the sites were generally free, they were quite severely limited in size, plastered with advertising and didn't help at all with building common web site features, like navigation, menus or consistent look-and-feel.

WYSIWYG Editors

Not long after the Internet started to take off — proving itself a viable market — companies like Microsoft and Macromedia started creating graphical front-ends (FrontPage and Dreamweaver, respectively) for writing web content.

These tools created content in a familiar way, hiding the complexities of HTML and Javascript behind GUIs that echoed familiar text applications like Microsoft Word. Even early versions contained a way of managing a site of documents with links between them and support for "templates", which ensured a consistent appearance.

Though these tools added a welcome layer of abstraction, they didn't offer much help when it came to developing web applications, front-ends for databases or other structured content. At this point, the tools had become accessible to more users, but their expressiveness was still severly limited.

Web Development IDEs

With the advent of web IDEs, programmers were finally able to develop web applications in a way similar to desktop application development. They had libraries of common functionality and debugging tools at their disposal, as well as seamless integration with databases.

Naturally, these tools are familiar only to developers and assume knowledge of concepts that are quite beyond the average user. Though they helped increase the overall quality and interactivity of corporate web sites, personal web sites generally languished at the same level as before.

Content Management Systems (CMSs)

Many ISPs have upgraded their Site Builders to CMSs, which are full-blown web site editing tools. Most of these tools have a web-based interface and offer almost-complete control over every detail of a web site. Though these tools aren't as complex as IDEs, their learning curve is prohibitive and the average user will never be able to use one effectively.

CMSs include modules or plugins for common features, like navigation and menus, and are generally stored in a database. However, these tools cannot be used for database development; the database functions simply as a storehouse of the site structure and content. Sites must still move to IDEs and server-side development when they need interactivity or structured content.

The steep learning curve for most CMSs means that, even if the ISP makes it freely available to subscribers, the average user won't be able to use it. Even businesses must be able to afford staff or hire consultants to maintain web sites built with CMSs.

Blogs and Wikis

Blogs are online journals; no more, no less. They automate the task of publishing text snippets, or entries, to the Internet. Entries can be viewed, edited and browsed by date and topic. Wikis are collaborative web sites wherein users can easily create new pages and sections and link them together.

Though proponents of these content systems would argue that they are quite different, they are almost identical in terms of expressiveness:

Limited Concepts: In general, an idea that a user can easily express on paper won't translate well to a single snippet of text. Structured data is beyond the reach of a wiki or a blog.
Limited Views: Both systems have a fixed number of ways of presenting their content, or views. The user can use "show entry", "show history", or "show this month", but cannot define new views without programming.

Since the most popular tools only allow linking text snippets together, it stands to reason that most personal sites are just that. But anything but the most primitive content has a much richer, more detailed structure than that. Even a blog or wiki entry is more than a bit of text: it has a creator, a creation date, a title, a description, a history and more.

There is no way that a user can create this kind of content with a wiki or a blog.

Munjari

A look at a typical community web site or larger personal web site shows a home page and that links into different areas: photo albums, MP3 lyrics, software downloads, recipes, community forums, and much more. Any one of these areas has a structure that is richer than simple pages; though it is possible to build the site with only text, it is far better to encapsulate these concepts as structured data.

Take, for example, a "downloads" section on a web site. Large software providers have software that can categorize, search and track many different products and versions. Even smaller sites need some of this functionality to avoid a quick-and-dirty solution that must be updated manually — but it takes too long to build. Even a developer isn't likely to build a solution with a database, much less a robust one.

The example above is just one of many; the introduction offers more. The point is that most users cannot build the sites they want with CMSs, Wikis or Blogs. These sites must be built with the next generation of tools; they must be built with Munjari.