Some demos show the user authorization concept. Logins and passwords are in the description of the demo under "Login information". Admin account is always: admin/pass.
I did not see that at all in my 'I didn't read the whole page' exploration, and ended up not really studying further because of it. That might be UI feedback for you, I guess. I'll take another look when I'm at my desk.
Same here, but considering we (I, at least) found the "launch demo" via a dedicated demo-page it was quite obvious to me that there would be passwords on that page, and there were.
I did get turned off from it though, so I guess the UI comment stands.
I didn't read. It's fair to blame me for that, but a lot of potential customers or users won't read. If I had a specific suggestion, I'd say to move the Launch Demo button to right above the Login info subheading. So it's hard to click it without noticing the login section.
Oracle (Hyperion stack), IBM (Cognos TM1 and maybe Controller), SAP (BPC), Infor (PM) are the big ones. Also, SQL Server Analytic Services is in a similar space but mostly from a BI, read-only perspective. Smaller include Jedox Palo (GPL but with a weird openness history) and many other vendors (e.g. Anaplan etc.)
No worries. I played around a little, given that I have done implementations with all the systems I mentioned above, and it looks interesting at first sight. I would have to look into it in more detail. By the way, I tried to create a new spreadsheet and it creates it (test) but when I try to view it, it gives me an error. It looks pretty easy for someone who knows what they are looking for, but others would be confused.
Thanks for testing.
There are some misleading error messages. I will look into it. The problem was you did not "apply metadata" (from the tools menu) after creating a spreadsheet.
If you have any ideas I would really like to simplify the UI. A spreadsheet gets much more complex with multidimensional data model. My idea was that people who are familiar with tools like TM1 or BPC would use the system to create planning solutions for their small and mid-size clients.
Just one piece of advise. Do not sacrifice usability for elegance. I can see you consistently apply a model that builds on metadata abstractions. Nevertheless, it is not conceptual consistency but expectations that should drive interactions. A difficult balance, given that consistency also improves accuracy of expectations but if you take big vendors, that consistency approach was taken to the limits by BPC. This is why everything feels like 10 extra steps. When someone creates artefacts they should be immediately available. The only thing that should necessitate a metadata application from a user perspective should be metadata (as in dimensions changes, not even member additions) and logic changes (if you need to optimise your calculations graph.) The rest should be transparent and separated at least visually from metadata. You can keep security in metadata, but calculation is a separate concept and you will most probably have to separate it when, as per your roadmap, you look into workflows. Do not get confused by the consistency. Look at the concepts from a user perspective and hide elegance in implementation if you can. I hope this helps. I will send you an email and we can discuss in more detail.
I don't understand it. When you said "multidimensional" I thought of it as a database that could be displayed as different spreadsheets from different viewpoints, but in the examples I cannot see the multidimensionality, nor where is the data coming from on each calculation, I don't see formulas anywhere also; and I can edit the values manually.
Multidimensional in this case refers to OLAP cubes. In other words, it's a relational database with a star schema.
The formulas in this case are built in the "metadata editor". The expectation is that a data scientist would build the tables, and then pass it off as an analysis tool to the MBA types. It can be really unintuitive if you've never seen these types of dashboards before.
Don't know about the specific implementation, but OLAP does not necessarily mean relational with a star schema. There is a distinction between ROLAP (Relational OLAP, which is what you describe, plus snowflakes), MOLAP (Multidimensional OLAP, which is true multidimensional, as in Essbase or TM1) and HOLAP (Hybrid OLAP, which is a combination of ROLAP and MOLAP as in SQL Server Analytic Services.)
Multidimensional means every cell of a worksheet is associated with multiple dimensions like year, month, company, currency and so on. This implementation is not really a ROLAP. Instead of a relational database I use a document database for storing metadata. You can access formulas via context menu on cells (grey cells have formulas on them, white are input). The whole thing has become a bit complex. Some information is in the docs.
27 comments
[ 3.2 ms ] story [ 59.0 ms ] threadI did get turned off from it though, so I guess the UI comment stands.
Who made it? Why?
What? Where? How similar? (I'm not critizing the copy, I'm just asking for more explanation, since I don't know anything about very large companies).
I am probably missing something.
The formulas in this case are built in the "metadata editor". The expectation is that a data scientist would build the tables, and then pass it off as an analysis tool to the MBA types. It can be really unintuitive if you've never seen these types of dashboards before.
Considering this (and my experience in the demo), this is probably not the nice tool I was imagining.
Check it out :)
EDIT: I see there are a handful of typos and incorrect/unclear wording. I'm writing you an email with the corrections I would make.