Archive for March, 2009

h1

How to find information on EPiServer Problems

March 19, 2009

When working with EPiServer at least earlier a big problem has been finding good help when you need to develop something. Like “How do I <insert problem> in EPiServer. Is there any examples I can look at?”. Some things might still be a problem to find but it is alot of information out there, you only need a way to find it. I will try to write of some ways to find the information you need.

Google

Off cause Google is always a good place to start. If you are lucky there is some nice results there and you can go home and develop happily. Sometimes though the really good results is not on the first page (might be some hard to find blog like mine) or are a part of a big result from like EpiServer world which might not show unless you go deeper into all results with multiple pages.The information probably is there somewhere in a result string but might be faster and easier to instead go down and check the top sources themselves directly instead.

EPiServer World

EPiServer World is a very good place to search for information. First it have a lot of information in blogs. A lot of very good developers have a alot of nice blog posts about various problems that they have found solutions on. To find information in the blog i suggest doing a search on EPiServer world page. You will also find results from forum posts, articles and episerver.com (White papers and such). And if you don’t find the result here or in any of the below links its a good thing to post a question in the forum. That way also other developers can see the question and answer of the problem you have, so they can find in when they need.

EPiServer Wiki

EPiServer Wiki is a newly started  wiki that will grow lot ain the future when people start using (at the moment it is pretty unknown). To contribute to this wiki you only need an EPiSevrer World account and then you can start write good information. i hope this will be a huge database of good stuff about EPiServer. Go there and try a search and see if you get the result you want. At the moment there is no developer information but I hope that will change.

EPiServer SDK

EPiServer SDK in an early version was extremely flat and really did not give that super much information. Sure you could find some nice information there depending on what you where looking at but it had a lot lacking. This have improved some lately and there are more helpful information here now even if it still lacks a bit. There are people that have as a job to create SDK content here so more come up every day.

EPiCode, EPiServer LABS and EPiServer Research

EPiCode, EPiServer Labs and EPiServer Research is a great place if you are looking for some modules that you think would be good or other new and cool features that is not officially supported but would fit your project perfectly. Most projects you find on these sites are Open Source projects that you can download, install and use on your site. It is very good to have some basic knowledge on the projects here so that you don’t do the same work yourself that have already been done. Its very much worth the time to visit these!

Livechat with EPiServer developers, support and partners

Livechat with EPiServer developers is a very nice way if you need fast information on a problem and have not been able to find in in your searches. In this IRC channel you will find EPiServer employees, EPiServer Partners and more that discuss EPiServer all day long so this is a really nice place if you have an urgent question. Or want to help other people with their urgent questions.

I hope I have helped you to find the solution to your EPiServer problem!

h1

Websites and Accessibility

March 18, 2009

I have just been to a workshop on accessibility lead by two persons with different sight handicaps. One that are working and using dayly readspeakers and one that uses zoom tool at work to be able to read and navigate the content of a website. They told us alot about what to take into consideration when creating a site and also what to stop doing. It was only a 2 hour workshop but it was very insightfull and told alot. The readspeaker that they used was JAWS and the zoom tool was Dolphin.

Some information from the meeting

Spending time on a website for functionality that reads the content automatically without using a readspeaker tool like JAWS is a big waste of time for their targetgroup. If the have disability, they have their own tools and if they are on a computer without their tools they wont be able to get to the browser or go the the webpage anyways. There might be other uses for such a tool like targetgroups that are weak in the language of the webpage and might benefit for hearing it instead of reading it, but most likly are not worth the developing time.

There are however alot to think about when building a webpage that have  abig beneficial effect towards readspeakers and I will lise some of them here.

Use  headings in a good structured way. Many sightdisabled persons navigate webpages using headings. Headings give a good structured overview of the page and what content it contains. Readspeakers have good tools for jumping between headings and this is the primary way they navigate a page. Also FireFox, Opera (and maybe more browsers) have toosl for testing this by only displaying a index of all headings on a page, try this to see that the page looks good and understandable (where to get what information) with only headings.

Another good thing is bringing back Anchor links to part of the page and have a index in the top (remember to have good titles on the links). That way  they can find what information or section of the page they need easily.

For zooming tools the website should not have too much empty spaces, flash/silverlight applications and such. If flash/silverlight is needed onthe page try different zoom tools on the page so that the applications zoom good. (sometimes they can even crash the zoom tool).

For more advanced help with accessibility you should really look inteo WAI-ARIA. Their comment on WAI-ARIA was that they ahd not had any experience with it but they said it sounded great, and a thing they really look forward too in the future. WAI-ARIA is still a very new technology to use and as such might be hard to find examples on how to, but it is worth looking in to if you want an accessible website.

Links

General information

W3C information on all WAI standards

WAI-ARIA information

Here is a link on for figuring out which browsers today have support for WAI-ARIA. Im not sure though on which rate this page is updated.

WAI-ARIA browser support

Video: Todd Kloots: “Developing Accessible Widgets Using ARIA”

EPiServerdagen 2009

EPiServerday 2009 had some seminaries with accessibility in swedish. So if you understand swedish here are some links for these:

PDF: Presentationerna för seminariet dag 2 accessibility i och med EPiServer

Video: Tillgänglihet 2010 – så skapar du webbplatsen alla kan använda

Video: Checklista inför de nya kraven på tillgänglighet 2010

Video: 2000-talet tillgänglighet på webben (With: Olle Ohlsson, W3C)

Video: EPiServer CMS och Tillgänglighet (With: Peter Sunna, EPiServer )

I hope that information will be usefull to you also, and please ask any questions you have and I might be able to help. I might continue and post more about this in the future.

h1

List of editors

March 17, 2009

Time to take a look at my first list of WYSIWYYG editors. to start ill just post the list as is with no ordering or comments. These are a list of unchecked editors.  I just listed as many editors I could find with some basic criteria. Firefox and Internet Explorer enabled and not like PHP, JAVA, or such serverside only. (since i will use asp.net for development).

Here is the list of the 28 WYSIWYG editors in the first line-up. please contribute with any extra editors you know of that could fit the list and is worthy of looking at.

Active Up Html TextBox
Active Up Html TextBox

Solmetra SPAW Editor
Solmetra SPAW Editor

Whizzywig
Whizzywig

Xinha
Xinha

Asbru Web Content Editor
Asbru Web Content Editor

Cute Editor for .Net
Cute Editor for .Net

QWebEditor
QWebEditor

Telerik RadEditor
Telerik RadEditor

WYSIWYGPro
WYSIWYGPro

Web Wiz Rich Text Editor
Web Wiz Rich Text Editor

Freetextbox
Freetextbox

OpenWYSIWYG
OpenWYSIWYG

NicEdit
NicEdit

EditLive
EditLive

Sferyx Jsyndrome HTMLEditor
Sferyx Jsyndrome HTMLEditor

Xopus
Xopus

Edit-on Pro
Edit-on Pro

Inspire Webedit
Inspire Webedit

Ektron eWebEditpro
Ektron eWebEditpro

Devexpress
Devexpress

TinyMCE
TinyMCE

FCKEditor
FCKEditor

Xstandard
Xstandard

Obout Editor
Obout Editor

Yahoo:s Editor
Yahoo YUI Editor

Component Art
Component Art

InnovaStudio WYSIWYG Editor
InnovaStudio WYSIWYG Editor

Inspire Webedit
Inspire Webedit

Some of these did almost autofail within seconds after opening the page and starting to evaluate the editor later in the evaluation process. But we felt it needed to atleast take a look at them so that we dont miss a WYSIWYG editor that is good.

h1

The WYSIWYG work begins

March 16, 2009

Well it has been quite some time since I last wrote anything as you can see. and it is time for me and for that I am sorry. I will not make any attempts to promise more postings but I will continue and tell you how this WYSIWYG process have been doing and the results.

The WYSIWYG work went on ice for a long time to be restarted early this year. and the first work was to figure out how we are going to achieve this.

First step: First step is to just brainstorm and define what is needed. We had two brainstorm areas that was requirements and list of editors. We just made a big list of all requirements or just questions like “Do we have keyboard navigation as a requirement?”. And for the editors we made a list of all editors we could find that had a remote possibility to be considered. In the editorslist we posted the name of the editor and a link to where there are more information on the editor on the web.

Second step: First step is as always research. We had to get a first requirements list and also a list of all the possible editors we could think of. With the requirements work we first identified some areas on what to write requirements on before we got into the meaty parts. This was the results of our requirement areas:

  • License model, pricing and company/organizational aspects
    Legal stuff and such. Like if it is a part of some fancy CMS it might be a problem etc.
  • Platform , browser, script and language support
    To make sure we can use the editor where we want to and that our target group of users can use it
  • Customizability
    Make sure that the parts of editor that we want to customize can be customized
  • Documentation and Support
    Make sure there are good documentation and support for the editor
  • Accessibility of user interface
    Check accessibility parameters like keyboard navigation and such for the editor.
  • Plugin Support
    Make sure we can make plugins for the parts we need and maybe also make sure there are some public plugins we can use/look at.
  • CSS Support
    Make sure the editor has good CSS Support
  • Code Rendering and Content Creation
    Look at the code the editor renders with its default functionality and make sure it is of good quality
  • Formatting Options
    Detailed look at what elements the editor can create and what attributes it uses at default installation.
  • Specific Requirements
    All other requirements that does not fit under the above headings.

Next time we will dive a little deeper.