For a long time, I have been thinking about client technologies and could not decide which one to choose. There is the web community and the the desktop community. Both of them have good reason for or against a technology. My problem is that I am pushed towards a web/browser-based solution which is by far not my preferred interface. Browser-based solution do not provide the comfort of interactivity a desktop solution can provide. Also, it relies on an existing and fast web access. But these solutions are the trend, hence, it is hard to argue against those.

The other day I came across an article in a German Java magazine which discusses different client technologies and presents an alternative I am happy with.

Fat Client. Historically, before the rise of the web, Fat Clients were the predominant technology. Deployment was one of the crucial issues here. Due to their monolithical structure, Fat Client applications are difficult to maintain and therefore, development costs were rather high.

Thin/Zero Administration Clients. They came up with the popularity of the Internet and solved at least the problem of deployment and they were less expensive. But browser incompatibilities, long loading times, and the lack of integration into web-based application prevented a lasting success. Applets were representatives of this architecture.

Ultra Thin Clients. These clients were very easily to install but they lacked interactivity. At the time, DHTML and Java Script was strictly forbidden.

Rich Clients. Because customers are rather interested in user-friendly GUIs, Rich Clients became popular again. Romain Guy goes one step further and presents an approach called Filthy Rich Clients. The clear emphasis is on the UI – Clients should have a really awesome and modern look including shadows, transparency, animations, etc. as known from the Mac.

Thin-/Fat Browser Applications. Deployment was no high priority issue for Rich Clients, but when the discussion on installation facilities started, solutions like Java WebStart did not become as visible as one might expect. Instead, a step back to asynchronous browser applications followed which were able to work offline. However, Data, Logic and Gui were still tied together such that reuse of components involved some investment of time.

Smart Interactive Clients. Adam Bien proposes in the article to separate GUI and Logic in Desktop Clients as it is done in application-framework architectures. That is, the same logic can be reused in server as well as in client applications. The difference is the GUI which in case of Java Desktop could be Swing and in case of a application-frameworks could be some web framework. The logic layere is accessed through some persistence layer. The client doesn’t know anything about the layer, it only knows logic action he can perform.

Have a look at Google Maps and Google Earth. Both share a common logic but Google Earth provides rich interactivity actions which include far more effort to be developed in a web framework.

Concluding, if you start to implement a new application and do not know what kind of architecture to choose, think in layers and consider persistency. At some point, you’ll make a decision for a browser-based or a desktop-based application. All you need to do is to implement the GUI.

The e-portfolio community is quite young and comprises people from different disciplines with different backgrounds and experiences. As a result, there are different views and definitions of an e-portfolio. Simon Grant, from UK, initiated in his paper Clear e-portfolio definitions: a prerequisite for effective interoperability, presented at e-portfolio 2005 in Cambridge, a discussion on e-portfolio terminology in order to find a consensus. In the German speaking community Thomas Häcker investigated the roots of the term “portfolio” and presents different definitions (see also Handbuch Portfolioarbeit).

One reason for the difficulty to grasp the essence of (e-)portfolios is that (e-)portfolio work originates from its application. It’s not a product of some theory. In contrast, the theory is being constructed from e-portfolio usage.

Having read lots of literature on e-portfolios, I came across a number of different definitions which I want to list in this blog. Apart of English definitions I am going to cite and translate German definitions as well. There is no common consensus for a definition, but some of them are more often cited than others. Also, they differ in their meaning and focus:

• (e-) portfolios as a product or a collection
• (e-) portfolios as systems/services/environments
• (e-) portfolios as means to support learning processe
• combination

A collection of authentic and diverse evidence, drawn from a larger archive, that represents what a person or organization has learned over time, on which the person or organization has reflected, designed for presentation to one or more audiences for a particular rhetorical purpose.

EDUCAUSE NLII

 

An ePortfolio is a personal digital collection of information describing and illustrating a person’s learning, career, experience and achievements. ePortfolios are privately owned and the owner has complete control over who has access to what and when. Is an e-portfolio a tool?

EIfEL
http://www.eife-l.org/portfolio/

E‑portfolios have emerged as a valuable online tool that learners, faculty, and institutions can use to collect, store, update, and share information. E‑portfolios allow students to reflect on their learning, communicate with instructors, document credentials, and provide potential employers with examples of their work

EDUCAUSE II (2005)
http://www.educause.edu/E-Portfolios/5524/

Portfolio ist eine zweckgerichtete Sammlung von Arbeiten und Dokumenten im Zusammenhang mit einem bestimmten Schulentwicklungsprozess bzw. Schulprogramm, die sowohl den Entwicklungsprozess als auch die -ergebnisse dokumentiert und reflektiert.

Meyer, Schumann, Angello (1990)

 

Ein Portfolio ist eine zweck- und zielgerichtete Auswahl eigener Arbeiten einer Schülerin bzw. eines Schülers, in welcher die individuellen Bemühungen, Fortschritte und Leistungen in einem oder mehreren Bereichen dargestellt und reflektiert werden.

Elfriede Schmidinger
Handbuch Portfolioarbeit

 

 

By portfolio, we mean a purposeful, interrelated collection of student work that shows the student’s efforts, progress or achievements in one or more areas. The collection includes evidence of students’ self-reflection and their participation in setting the focus, selecting the contents, and judging merit. Acrivities are guided by performance standards. A portfolio communicates what is learned and why it is important.

And in German:

Ein Portfolio ist eine zielgerichtete Sammlung von Arbeiten, welche die individuellen Bemühungen, Fortschritte und Leistungen der/des Lernenden auf einem oder mehreren Gebieten zeigt. Die Sammlung muß die Beteiligung der/des Lernenden an der Auswahl der Inhalte, der Kriterien für die Auswahl, der Festlegung der Beurteilzngskriterien sowie Hinweise auf die Selbstreflektion der/des Lernenden einschließen.

Pearl and Leon Paulson; Meyer (1992)
What makes a portfolio a portfolio?
in Educational Leadership

A portfolio can be defined as a purposeful collection of student work that tells the story of a student’s effort, progress and or achivement in a given or several areas.

Wade and Abrami (2004)

A digital portfolio or e-portfolio is a collection of learner’s work that can include text, pictures, hyperlinks and different multimedia elements.

Ahonen and Murto (2004)

Portfolios, as the name suggests are mobile containers for artifacts in a range of media.

Hartnell-Young (2004)

… the term ePortfolio … tends to be seen as a toolbox for the student and the knowledge worker.

Home and Charlesworth (2004)

The e-portfolio is an information management system that uses electronic media and services

Haywood and Tosh (2004)

Hartnell-Young (2004)