Html As Doc Format

ConstEdit is a word processor that writes documents in the html format. Why bother to choose html as the format for office or personal documentation purposes, instead of sticking with old formats that are already widely used such as doc, docx, odt or rtf ?

The most popular and future-Proof format

The fact is that html is the most widely used document format. It is the de facto standard of all internet webpages. This format is practically future-proof because of its popularity. You don't have to worry that the format of your documents will one day become obsolete and have to go through another round of converting old documents to some newer format.

Html as a document format in fact is already supported by popular online and desktop document editors such as Google Docs and LibreOffice Writer. There is absolutely no worry that the format will one day become unsupported for editing.

For bloggers, there is an additional benefit of supporting html. While regular word processors are not meant for webpage designers, you can, at least with ConstEdit, copy the underlying html source code conveniently from ConstEdit to the clipboard. If your blog authoring tool accepts html source code (e.g. Google Blogger), you will find it very handy to insert complex html elements such as tables into your own webpage. Or you can do it the other way round, copy data directly from webpages into your document, without loss of the formatting.

Share your documents more easily

By using html as the format for documentation, there is no need to invest on installing any special software for viewing the documents. Your favorite web-browser will do the job because your documents are actually webpages. You can share your documents more conveniently. Your documents are viewable in all common computer operating systems. This is a document format that is truly cross-platform.

In a business environment, documents sharing can be implemented by simply putting the documents on to the company intranet or on to the cloud. Viewing is done through a web-browser which should be available in every desktop pc or mobile device.

Total Separation of content from formatting

A shortcoming of common word processors is that you have to set the formatting of your sections, section titles, sub-sections, tables,... etc at the same time when you are writing your document. A significant % of your effort is thus wasted, while you, as the author, should be concentrating only on the authoring part.

The html format overcomes this by separating the presentation layer from content authoring. The formatting is done through an external stylesheet, which pre-defines how relevant html elements, such as sections, section titles, sub-sections or tables, are formatted in the document which the stylesheet is assigned to.

The styling is done automatically according to the stylesheet, at the same time while you are writing the document. E.g. when a new section is inserted, the new section is already rendered with the designed style with the correct numbering on it; when you demote a main section to becoming a sub-section, the numbering on the section title is updated immediately and the section is re-styled as a sub-section. There is no more need to set the styling manually and repeatedly.

Another advantage of using external stylesheets is that you can change the look of old documents to become more modern or stylish by simply updating the stylesheets, without touching these documents. All documents pointing to the stylesheets will have the new fresh look the next time they are opened. This benefit is particularly valuable in a business environment where a standard and consistent document formatting style is often desired.

ConstEdit provides a function for you to design and create your own stylesheets for styling documents to your own taste.

Sections structure management with html5

Html5 provides elements specially designed for the purpose of document sectioning. There is no longer any need to infer section structures from text formatting styles, as it is now done with many existing document formats. With html5, you can visualize your document structure more easily. This is particularly useful if you are used to writing your documents in the top-down approach; i.e. you determine the document structure first, and then go into the detail of each section.

Html5 sectioning elements are used in ConstEdit. You can now visualize the big picture of your document easily and manage sections structure with drag and drop. This is much like novelists re-arranging their storyboards.

6 comments:

  1. Hello, I am new to HTML5 and seek to make a stand alone client web app that I can post as a single HTML5 that contains:

    A Letter or Presentation
    An On Demand live peer to peer chat

    Is this possible to layout this with your app? Using an iframe or WHAT YOU MIGHT SUGGEST for the chat. I like your concept because I can change the content rapidly. I am seeking ability to rapidly change content in a responsive deployable "container".

    Any thoughts are greatly appreciated.

    Jon Alex
    nathansuigeneris@hush.ai

    ReplyDelete
    Replies
    1. Hi Jon,

      Thank you for leaving a comment here.

      First of all, I would like to make it clear that while ConstEdit would certainly help you create html documents that can be displayed by webbrowsers directly just like any webpages, it does not process or support any active content such as javascript, for security reasons and for the design purpose of the software. It is meant to be an html document authoring tool, i.e. a word processor, rather than a development tool.

      As far as your requirements are concerned, this is my very preliminary thought. The first part, the letter or presentation can be kept as a document on the cloud, and is thus possible with ConstEdit. The second part, the p2p chat, should be done with an appropriate IT development tool. You then use an iframe to point to the cloud document, and place the iframe into the p2p chatting webpage.

      Hope that this helps.

      Regards,

      Francis Shum

      ConstEdit Software

      Delete
  2. Great idea - I have been wondering about such a concept for some time myself. However, having just installed it I have to give some feedback on the user interface, because it's a mess. That area of shortcuts between the menu and the main editing area looks dreadful on a wide screen and wastes a lot of valuable screen real estate. Microsoft had it right in the pre-Office 2007 days - everything accessible via menus, and allow the user to activate the few shortcuts that they use the most. As well as there being far too many shortcuts, the problem is that they adjust their size relative to the screen, which makes them look ridiculous on a wide screen. Shortcuts should be absolute-sized and should automatically position themselves by wrapping when you reach the end of the line (like the characters on screen in a work processor).
    Make that change and ConstEdit will immediately look professional and be a lot more usable.

    Regards.

    ReplyDelete
    Replies
    1. Hi Michael,

      Thank you for commenting on the user interface of ConstEdit.

      The ui of ConstEdit is actually designed by making reference to the ribbon ui of the post-Office2007 days. The advantage of the ribbon ui is its clarity and the saving of keystrokes. All available functions are directly visible and accessible without having to give it a mouse click first, as in a conventional pull-down menu. The disadvantage is the wastage of screen real estate.

      The toolbars of ConstEdit attempts to achieve the same advantage of ribbons while saving some working space. The design is a compromise between the pull-down menu and the ribbon. The end user can actually toggle the visibility of each individual toolbar, if he/she decides to give working space priority over the accessibility of the ui.

      The toolbars are also designed to be "elastic", so that they always adjust to full window width. This is so that all shortcuts on them are always at the same relative position with respect to the window width; a shortcut, say at the right hand side of a toolbar, can always be located at the right hand side, at any window width. Thus these shortcuts can be located more easily and more quickly, at any window size. In the conventional non-elastic toolbars, there is wastage of working space if the toolbar is set to wrap at overflow, and if the toolbar is set to not wrapping at overflow, you need to give an additional mouse click to see all the shortcuts on it.

      I do agree that the text on these shortcuts can look funny if the app is maximized on a wide screen. But the text remains very legible. Also we suppose the most common way to make the full use of a wide screen is to place two apps side by side, so that referencing another app can be done at the same time when working on an app. Each app will look like a piece of A4 paper in the portrait orientation, which is the most preferable window layout setting for ConstEdit because it feels more like typing on paper.

      Thanks again for your valuable comments, and we sincerely hope that you can give ConstEdit a serious test drive. We look forward to more comments from you.

      Regards,

      Francis Shum

      ConstEdit Software

      Delete
  3. Hi Francis. There are two basic issues here:

    1) If this is inspired by Microsoft's ribbon, then I'm afraid it shows a misunderstanding of the rationale behind the ribbon.
    2) The ribbon was a poor solution to a problem that didn't exist anyway.

    At the launch of Office 2007, Microsoft explained that the purpose of the ribbon was to prevent users from consuming lots of valuable screen real estate by turning on every toolbar icon available. At the time I considered this to be a ridiculous reason because only the mentally retarded would turn on all the toolbar icons, and laudable as it is to produce software specifically catering for this underprivileged section of society, I don't see that it aligns well with Microsoft's strategic goals. The whole point of toolbars was to allow the user to select the few functions that they would want to initiate by mouse most frequently - activating large numbers of them defeats the purpose as it becomes progressively more difficult to locate the icon that you need as the total number increases.

    Those of us who are power users avoid the mouse because it is much slower than the keyboard - we use keyboard shortcuts instead. For us the menu structure was ideal because it took up next to no screen space but could be navigated much faster by keyboard than even a toolbar icon could be activated by mouse.

    Microsoft attempted to get the best of both worlds with the ribbon, as it is in effect a graphical menu - every item is accessible via either keyboard or mouse, and it can be configured so that when at rest it consumes no more space than a traditional menu bar. Sadly whilst the theory is good, in practice the Office teams made a mess of the structure from a keyboard-based performance perspective. For example, pre 2007 one could initiate Paste-Special via three keypresses (ALT, E, S), whereas today the same functionality can require six keypresses (ALT, H, V, S, S, ENTER).

    Your argument about making your icons elastic in order to make their relative position permanent has some merit, but I would dispute your claim that the text remains quite legible irrespective of width. Actually I think the problem may not necessarily be the wide screen - the text is not very legible at any width, and some of the icons next to the text are particularly indistinct. The ability to hide the toolbars is helpful, although not intuitive - I had not made the connection as to what the row of icons on the menu bar was for until you explained this.

    In summary, I would suggest employing either of Microsoft's UI systems - either provide a proper ribbon with all the functionality (especially keyboard activation) of Microsoft's (I think there may be functionality in the Office SDK to allow you to easily create your own ribbons from XML), or provide menus and shorter toolbars (using icons and tooltips rather than text). What you have here is a halfway house that from the perspective of this user is not as good as either.

    If I had the time I'd offer to help you myself, as I really like the concept. I am impressed that you have managed to find the time to make a product that people are actually downloading and using - it's more than I've yet managed to do in my spare time.

    Regards,
    Michael

    ReplyDelete
    Replies
    1. Hi Michael,

      Thanks for your valuable comments.

      As far as the debate of the ribbon vs the pull-down menu is concerned, I think the whole point drills down to using the mouse or the keyboard : which is faster or easier. While I admit that using the keyboard is the faster way for "power" users, using the mouse is the more intuitive because you do not need to get used to those shortcut keys. In my humble opinion, the ribbon is actually not designed for the power users. And I believe most of the users are not power users, and I am not a power user myself. Also remember one point, how quickly you author a document doesn't really depend on how fast you type but what kind of functionality is available from the app and how comfortable you are when working with the app so that you can concentrate on the thinking rather than on the ui. I believe the ribbon ui is more comfortable to use, though not quicker, than a pull-down menu.

      On examining carefully the text on each of the ConstEdit toolbars, I agree with you that some of the text are not immediately recognizable even at a normal screen width. I will see how this can be improved.

      By the way, just fyi, there is already a ribbon control in dotnet; there is no need to get the Office SDK.

      Thank you for your offer to help with this app. Though there is no such need at the present stage, I still appreciate the offer very much.

      Thanks again for your comments and your very kind offer.

      Regards,

      Francis Shum

      ConstEdit Software

      Delete