At Lotusphere 2010 IBM introduced Project Vulcan. By the looks of it it looks like this is not "foilware" but actually working software. No I do not belive that you could by IBM Lotus Vulcan as a product any time soon. I see it as project term for the future workplace, where IBM tries to incorporate several technologies.
IBM did not aquire Java, Orcale did. I do belive that this will mean less development based on the Lotus Expeditor framework. For Lotus developers the focus will be on X-Pages, CSS, HTML5, and ofcourse Web Services.
There will come the time where notes application based on traditional Forms an Views and LotusScript code stored in events will be considered as Notes Legacy Applications. These type of applications will be difficult to embed in the new Lotus offerings like Lotus Connections, Lotus Quikr and in the cloud like LotusLive.
IBM has included X-Page rendering in the 8.5.1 Lotus Notes client. A smart move but I do think this is only to ease transition from a Rich Client architechture to a Web based one (Project Vulcan?). Lotus developers would do better to focus on X-Pages, CSS, HMTL-5, REST for future development.
Showing posts with label Lotus Development. Show all posts
Showing posts with label Lotus Development. Show all posts
Friday, August 06, 2010
Friday, May 16, 2008
Configuration documents - 'Best of Breeds' solution
Reading the assono.de web site I came across a tip from Thomas Bahn. As I'm not as steady in german, I had ot use the Babelfish to translate from german to english. Much can be said about the translation but I'll leave that alone for now. On to the tip...
It's a 'Best of Breeds' Solution approach to configuration documents or setup documents.
Profiledocuments has been much used to create and access database\application setup information. This solution is fast and the code to write and access the data is clean and slick.
However profiledocument has been prone to errors when it comes to replication and ofcourse is cached when loaded. Especially when using profile documents to hold counter, sequnencenumber, workflow status and such, this will be a problem.
The solution is simple but elegant:
1. Create the setup/configuration document using normal document creation methods like @Command[Compose];"MyConfigDoc")
2. In the QuerySave or PostSave add code to create a Profile document containing only the setup documents UniversalID.
@SetProfileField("ConfigUNID" ; "ConfigUNID" ; @Text(@DocumentUniqueID) )
Now You haver Your profile document with the UNID that references the Configuration document. Extracting the data from the document is as easy as this:
ConfigDocID := @GetProfileField ("ConfigUNID";"ConfigUNID");
@GetDocField (ConfigDocID; "Config_CustomerEmail")
This is not much different than the direct use of ProfileDocument:
@GetProfileField ("MyConfigDoc";"Config_CustomerEmail")
Notice that You only need one line of extra code in the 'Best of Breeds' Solution.
This example only shows implementation using Formula, LotusScript should be just as easy to implement.
It's a 'Best of Breeds' Solution approach to configuration documents or setup documents.
Profiledocuments has been much used to create and access database\application setup information. This solution is fast and the code to write and access the data is clean and slick.
However profiledocument has been prone to errors when it comes to replication and ofcourse is cached when loaded. Especially when using profile documents to hold counter, sequnencenumber, workflow status and such, this will be a problem.
The solution is simple but elegant:
1. Create the setup/configuration document using normal document creation methods like @Command[Compose];"MyConfigDoc")
2. In the QuerySave or PostSave add code to create a Profile document containing only the setup documents UniversalID.
@SetProfileField("ConfigUNID" ; "ConfigUNID" ; @Text(@DocumentUniqueID) )
Now You haver Your profile document with the UNID that references the Configuration document. Extracting the data from the document is as easy as this:
ConfigDocID := @GetProfileField ("ConfigUNID";"ConfigUNID");
@GetDocField (ConfigDocID; "Config_CustomerEmail")
This is not much different than the direct use of ProfileDocument:
@GetProfileField ("MyConfigDoc";"Config_CustomerEmail")
Notice that You only need one line of extra code in the 'Best of Breeds' Solution.
This example only shows implementation using Formula, LotusScript should be just as easy to implement.
Thursday, January 24, 2008
Yikes It Looks like that? UI Worst Practices.
Her presenteres vi ulike "Worst Practices" for grensesnitt.. og hvordan vi kan gjøre det bedre.
Vi skal lære av andres feil ;-).
I Notes kan vi lage applikasjoner så raskt at vi glemmer UI! (Notes is a RAD application). Men brukere liker ikke applikasjoner som kaster bort brukernes tid. Og brukerne er nå bortskjemt med gode applikasjoner på web. (Yeah Buzzword again: WEB 2.0).
1. Please!!!
Lag feilmeldinger som brukere forstår, og hvordan feil kan rettes eller hvem skal meldes om feilen. Og en feilmelding kan jo være stilig. Og det finnes en base med gode feilmeldiner for alle de rare kodene som Lotus kan komme opp med.
2. Bruk riktige kontroller, Checkbox'er, Radio Button osv.
Vi skal lære av andres feil ;-).
I Notes kan vi lage applikasjoner så raskt at vi glemmer UI! (Notes is a RAD application). Men brukere liker ikke applikasjoner som kaster bort brukernes tid. Og brukerne er nå bortskjemt med gode applikasjoner på web. (Yeah Buzzword again: WEB 2.0).
1. Please!!!
Lag feilmeldinger som brukere forstår, og hvordan feil kan rettes eller hvem skal meldes om feilen. Og en feilmelding kan jo være stilig. Og det finnes en base med gode feilmeldiner for alle de rare kodene som Lotus kan komme opp med.
2. Bruk riktige kontroller, Checkbox'er, Radio Button osv.
3. Bruk farger riktig!!
Notes applikasjonen skal ikke se ut som Smarties.
Bruk farger som er i samme farge palette. Vet du ikke hva det er? Google it!
4. Ikke la Domino Server bestemme design på web.
Bruk CSS, Dojo, Ext.nd osv. Domino UI har ikke endret seg siden 1997.
5. Tabs gone wild.
If you see a "twidgie" you have to many tabs. En "twidige" er disse pilene du får når du har for mange tabs. Ikke ha mer en 6-8!
6. If they can't do it, don't show it.
Ikke vis nagivering, knapper osv som brukeren IKKE har lov å trykke på.
7. Skjerm og papir er ikke det samme.
Lag 'Printer friendly' versjon av dokumentene.
8. Composite Applications.
Dette er vanskelig, og det er lett å gå overbord med dette. Desktopen i "composite applications" må ikke i sum bli for vanskelig. La komponentene handle sammen og relatere til hverandre.
9. Poler applikasjonen din.
Ikke gi brukerne default Lotus Domino design.
10. Alt trenger ikke å se ut som 'Notes Mail'.
Tenk nytt. La brukere filtrere informasjon, søke, presentere i rapport (alt trenger ikke være i et view).
Du trenger ikke alltid ha 2 -3 ui pane.
11. Business drives applications, applications drives infrastructure.
Admin bestemmer ikke hva som er lov og ikke lov.
12. Your App is not a video game.
Grafikk skal ha en hensikt.
Forsiktig med bakgrunner.
Ikke kast bort plass, ikke plasser ting for tett.
Husk fargevalg.
13. Don't asume.
Hvor lett er det ikke å anta at brukerne tenker det samme som deg?
Gi gode hint om hva som forventes eller hva som kan gjøres.
14. Feedback!
Brukere har
Oppsummert:
Ui må være logisk, klart og konsist og lett å bruke.
Subscribe to:
Posts (Atom)