Rethinking Notes
•Download as PPTX, PDF•
1 like•609 views
Rethinking Notes Session presented at MWLUG 2016 by Peter Presnell and Nathan Freeman. An update on our latest thinking on new and exciting ways to present and make use of existing Notes data.
Recommended
More Related Content
What's hot
What's hot (7)
Viewers also liked
Viewers also liked (20)
Similar to Rethinking Notes
Similar to Rethinking Notes (20)
More from Red Pill Now
More from Red Pill Now (18)
Recently uploaded
Recently uploaded (20)
Rethinking Notes
- 1. Rethinking Notes Peter Presnell CEO Nathan T Freeman Chief Software Architect
- 2. Hands On Graphs Rethinking Notes Design Matters Web Components Lotus Position Wednesday 4:30 PM Thursday 1:00 PM Thursday 1:00 PM Friday 9:00 AM Friday 10:15 AM Nathan Freeman Bob Kadrie Keith Strickland Peter Presnell Nathan Freeman Kito Mann Keith Strickland Peter Presnell Clarence White Case Study
- 3. Challenge the way you think about Notes data
- 6. The Average Company 200Notes Applications
- 9. Time To Rethink Notes…
- 10. Wheel of Destiny Rethinking Databases Rethinking Data Silos Rethinking Data Schemas Rethinking Web Development Rethinking Forms Rethinking Addresses Rethinking Dates Rethinking Search
- 11. Rethinking Dates
- 14. REALLY?
- 15. Date Picker
- 16. Time Picker
- 18. Milestones Today In 5 days time Next month In 3 months 3 days past due
- 21. Notes Databases Supplier Form Order Form Supplier Documents Order Documents Orders By Supplier View Embedded View @DBLookup
- 22. SQL Databases Supplier #1 Supplier #1 Supplier #1 Order #101 Order #102 Order #103 Supplier #2 NULL Supplier #1 Supplier #2 Order #101 Order #102 Order #103 Join
- 23. No SQL Databases Supplier Form Order Form Supplier Documents Order Documents Orders By Supplier View
- 24. REALLY?
- 26. Try this one with Notes…. Supplier #1 Supplier #2 Order #101 Order #102 Order #103 Item #1 Item #2 Item #3 Item #4
- 28. Any document can be a vertex Suppliers (NSF) Orders (NSF) Supplier Order Item
- 29. Any view entry can be an edge Supplier Order Suppliers (NSF) Orders (NSF) Orders By Supplier
- 30. Any edge can be a document Supplier Order Suppliers (NSF) Orders (NSF) Edges (NSF) Orders
- 31. Proxy documents can support graph-only data PersonPerson Directory (names.nsf) Person Proxy (NSF) Office Locations (NSF)
- 32. Any form can be a frame Supplier Form Order Form Supplier Order
- 33. And not just Notes Employee Directory (Names.nsf) Employees (Employees.nsf) Active Directory
- 36. Traditional (Notes) Data SchemaItem Value Type FirstName Ray Text LastName Ozzie Text FullName Ray Ozzie/RedPill Name DOB 11/20/1955 Date EMail Ray@redpill.com Text EmployeeNo 1001 Number Spouse Dawna Bousquet Text JobTitle Evangalest Text City Redmond Text State WA Text PhotoURL Pho.com/ray.png Text Item Value Type FirstName Ed Text LastName Brill Text FullName Ed Brill/RedPill Text email Ed@redpill.com Text EmployeeNo 1002 Text JobTitle Product Manager Text City Highland Park Text State IL Text PhotoURL Pho.com/ed.png Text
- 37. UNK Table FAX FullName Text Name LastName Text UNique Key Table Supplier Form EmpNum: Text Supplier Form EmpNum: Number Full Text IndexEmpNum Text
- 38. REALLY?
- 44. ContactCard
- 46. Employees
- 47. Officers
- 48. Cadets
- 49. BandMembers
- 50. Rangers
- 51. Volunteers
- 52. Counselors
- 53. Counselees
- 55. AidRecipients
- 56. Donors
- 60. Case Study: Salvation Army Divisions
- 62. Corps Details Division Form Corps Form Division Documents Corps Documents Corps By Division View
- 63. Disposition of Forces DHQ Form Corps Form Division Documents Corps Documents Corps By Division View
- 65. Officer Management System (OMS) Division #1 Division #1 Division #1 Corps #101 Corps #102 Corps #103 Division #2 Corps #201 Division #1 Division #2 Corps #101 Corps #102 Corps #103 Join
- 67. And yet other databases “ALM” “AOK” “FLA” “GEO” “KTN” “NCV” “THQ” “TXS”
- 68. Data Mismatches • ALM • Alabama Louisiana & Mississippi • Alabama Louisiana and Mississippi • Alabama, Louisiana & Mississippi • Alabama, Louisiana, and Mississippi • Alabama, Louisiana and Mississippi Use the force, Harry - Gandolf
- 69. REALLY?
- 71. Database Cleanup Corps Details Dispo OMS REST Services
- 72. Database Cleanup Corps Details Dispo OMS REST Services
- 73. Database Cleanup Corps Details Dispo OMS REST Services
- 76. In the future…. OMS REST Services OMS Next
- 80. Mailing Labels
- 82. REALLY?
- 85. GPS Location
- 87. Or even…
- 90. Built on aging technology SSJS = ES3 (1999)Eclipse 3.4 (2008) HTTP Servlet (2005) Java 6 (2006)
- 91. XPages roadmap
- 92. REALLY?
- 94. RESTServices
- 96. Java Servlets
- 98. Web Components
- 99. Polymer
- 100. Vaadin
- 101. REST API HTML 5 Structure CSS 3 Style JavaScript Behaviour
- 102. REST API HTML 5 Structure CSS 3 Style JavaScript Behaviour
- 105. Rethinking Search
- 107. Now considered old school… Word Variants Fuzzy Search Form Searches
- 108. Traditional Notes categorized views
- 109. Now considered old school… Response Documents Conflict Documents Categories
- 110. Domain Search
- 111. REALLY?
- 112. Faceted Search
- 113. Faceted Search
- 114. Faceted Search
- 115. Faceted Search
- 116. Faceted Search
- 117. Faceted Search All Documents By Form View Person Job Company Group University All Documents By Location View United States United Kingdom Greater New York City Canada Australia
Editor's Notes
- After alll…. There are 10 million Notes applications out there.
- The average company has an estimated 200 Notes applications in us
- With the Notes client sunsetting most IT Managers are looking for ways to provide modern Web front-ends to these
- In recent years there has been a ground-swell of support for no SQL alternatives. Of course Notes databases have been doing No SQL for over 25 years, long before they became popular. In a Notes (document) database we would represent Suppliers and Orders as different sets of documents. To represent the relationship between the two we would use a combination of embedded views in a form or computed fields on a form the use @DBLookup to locate the related information. Consolidating the data in a view is almost impossible. Outside of response documents there is no simple way to connect related information together at the data layer. So a simple construct such as Suppliers and Orders can sometimes be challenging in Notes client development.
- When it comes to storing data in a database, SQL has for many years been the defacto standard. In the SQL world, if we have two business objects such as a a Supplier and a Customer we would represent that relationship using a SQL Join.
- In recent years there has been a ground-swell of support for no SQL alternatives. Of course Notes databases have been doing No SQL for over 25 years, long before they became popular. In a Notes (document) database we would represent Suppliers and Orders as different sets of documents. To represent the relationship between the two we would use a combination of embedded views in a form or computed fields on a form the use @DBLookup to locate the related information. Consolidating the data in a view is almost impossible. Outside of response documents there is no simple way to connect related information together at the data layer. So a simple construct such as Suppliers and Orders can sometimes be challenging in Notes client development.
- Really? In 2016 we don’t have a better way to represent relationships between documents held inside an NSF?
- There is a solution if you care to challenge the conventional approach to storing data inside an NSF. It turns out that the characteristics of Notes databases are not all that dissimilar to those of Graph databases. Here we can conceptually see the relationship between a supplier and orders as represented using a graph structure.
- If we add just one more object type (Item) we quickly get an application that is immensely complicated to reproduce in a traditional Notes application without making a lot of compromises on the user experience.
- The solution is to extend the capabilities of the Notes File Store (NSF) to support the capabilities of Graph as defined by the Tinkerpop interface. Allowing any Notes database to behave as a graph database.
- In essence any document stored in an NSF can become a vertex in a graph
- View entries can be used as edges to automatically connect related information.
- If edges between vertices do not exist it is possible to store those edges as new Notes documents.
- To protect the data integrity of existing Notes applications it is possible to create proxy documents that acts as surrogates for existing documents holding the additional data needed to support a graph structure used in new Web applications. This can include new properties for a vertex as well as the information that stores the relationship between vertices (edges).
- Documents stored using Notes Forms can be represented as frames, allowing access to a collection of documents created using a specific form.
- And best of all, there is nothing in this approach that excludes data stored in formats other than Notes allowing a graph to be built using data stored in Notes, SQL, and No SQL databases alike.
- Graph and ODA allows organizations to think big when it comes to mapping the complex relationships between data held across a portfolio of Notes (and non-Notes) databases, allowing information to be displayed that transcends the traditional boundaries artificially created by databases.
- When you look at most Notes applications that store addresses you will find a familiar pattern. StreetAddress StreetAddress2 (optional) City State Zipcode Country (optional) This will be repeated for each and every address such as Business Address and Home Address As a result we are often storing as many as six fields for each and every address.
- And why do we do that? Well the origins this fall back to the era in which everything with sent via mail. No, I am not talking about e-mail, but physical (snail) mail. One of the many features built into the Notes client that is rarely used is support for mail labels when printing a collection of documents. If you Notes applications are not printing mailing labels, why are you still splitting addresses into so many
- In 2016 it is kind of up there with modem. For the millennials in the audience the device on the right is called a telephone, and the device on the left is a modem that was used to connect a computer to the Internet via the telephone…. Yes these things really did exist.
- Really… thats the way we store addresses in the era of Google Maps
- Here we see an example of a page from the Salvation Army’s US Western Territory that helps locate SA Locations near a specic zipcode. And while the data in this case is not coming from a Notes database, it could be (and soon will be).
- And if I am using a device equipped with GPS I shouldn’t need to explain where I currently live. The application should know.
- Users of applications today expect a single address field. And not just that, but one that supports typeahead.
- Perhaps even one that shows in real time a map for the address matched address to quickly verify the address is correct.
- If you follow IBM’s advice you would migrate to XPages, a server-sided platform based upon JSF that it carried over from its failed Workplace venture.
- And a non-existent roadmap
- Is that the best you can do IBM… Really?
- First lets start with something we do agree… There is no need to discard your Notes data. Data is not the issue. Moving to SharePoint, Mongo DB, or SQL servers doesn’t solve anythig.
- Instead, what is needed is a robust REST interface that allows Notes data to participate as a first class citizen in modern Web development
- The simplest way to start is to utilize DDS which requires enabling at both the database and view level to generate REST services for Notes databases. The JSON generated can be somewhat difficult to use.
- To get around that, consider creating your own Java servlets that will allow full control over the JSON. This can be especially useful if you are wanting the JSON to conform to a specific data schema such as those outlined by schema.org.
- Having created a REST API for your databases we would strongly recommend adopting a JavaScript framework. There are many of these now on the market. While we have our preferences we consider it far more important to embrace one of these rather than waste too much time debating which (if any) is superior. To do so would be like trying to get a consensus as to which city is the best one to live in….
- At Red Pill Now we believe Web Components are going to play a very important role in modern Web development in much the same way as jQuery. For this reason we would urge everyone to find a JavaScript framework that implements Web Components.
- Our favorite is Polymer. We selected Polymer because it has an implementation of Google’s Material Design, has strong cross-browser support, provides good software engineering principles, and great performance characteristics.
- We would also strongly recommend the use of Vaadin controls such as the grid and dropdown to build great looking web applications.
- So here is what our modern web development architecture looks like… First, we keep our Notes data in-place allowing existing Notes client and XPages applications to work as before. This means a lot less risk. Next we build a REST API around each Notes database. This can be done in a range of ways including the Domino Data Service On top of that we develop Web applications using your JavaScript framework of choice. In the case of The Salvation Army we are focusing on the use of Polymer to implement Material Design and Web Components. This delivers code that conforms to the standards of HTML5, CSS3, and JavaScript that are mow well supported by modern web browsers.
- Then over time your organization is free to mix and match the database formats used as a decision separated from the front end applications now in use.
- Without doubt Google have been the thought leader when it comes to Search.
- Notes users will be familiar with the Notes client search bar. A mechanism that was made available in the later parts of the 20th century and had barely changed since.
- Ideas such as Form Searches, Fuzzy Search, and Word Variants were new and innovative at the time but are no longer relevant in the 21st century.
- To help find content in Notes databases we continue to rely things like categorized views.
- Using categorized views as a way of finding information makes about as much sense in 2016 as it does to display conflict documents or response documents. The world outside of Notes has moved on in the 2st century leaving Notes applications and views especially and outdated for of information discovery.
- And then there is the quest for a domain search capability. A feature that first Lotus and later IBM have promised to provide a solution but never really delivering on that promise. What does it say when it is easier for your users to find information outside of their company than it is to find information indside the company?
- Really IBM… This is the best that we can do for search.
- If you visit Web sites such as Amazon and search for Lotus Notes you will the common use of facets as a way to filter in on information
- If you visit Web sites such as Amazon and search for Lotus Notes you will the common use of facets as a way to filter in on information
- Same at ebay
- Yelp
- And Linked In
- SO how can we achieve this with Notes data? What if linked-in was a Notes database? We would want to have a Documents by Form View and a Document by Location View
- This wuld be denoted by the presence of facets Object (Form) and Location
- When we select “Company” as our Object, pur search results would be constrained to just those in the By Form View where the Form is “Company”
- Using a By Form By Location view we could then further constrain the results to those in the Company (Form) and US (Location) category.