Evan I like that idea too...we will have an extra kicking safe wallet though...
Hang on a minute. I think it's important not to drift unconsciously into uncharted waters. (Drifting "consciously" is ok
).
IMO, Dash as a product / brand needs to be either very LIKE bitcoin or very UNLIKE it. i.e. I think it's important to have a conscious strategy of either TOTAL compatibility and consistency in almost every aspect with bitcoin,
or a completely distinct identity and feel.
My own preference is for the total consistency and compatibility route. I have 25 years uninterrupted full time professional experience in business software development and user interface design and one of the banana skins I'm constantly aware of in this sector is that something that looks like "a great feature" to you can look a totally alien impediment to someone else who's used to some aspects of the design but not others. It can make them feel like they're in a non-authentic environment and that can offset any advantages the feature has. (There are of course constructive ways to implement alternative features which are not in people's faces - Dash has been very good at doing this IMO).
One of the huge advantages Dash has is that a Bitcoin user can make a seamless transition from the bitcoin environment and feel totally at home with Dash. However, that advantage can be lost with something as simple as a colour background difference which new users can find off putting due to simple unfamiliarity.
Having the QT wallet a'la Bitcoin with the extra mixing features is a great think IMO. It's exactly like bitcoin QT in every respect and the only thing that stands out is the distinct functionality advantage Dash has. There's no loss of authenticity by playing about with non-standard colours or other gimmickry.
I'm not trying to lay down any law here or say close any doors, just saying that this area (lets call it "tech-authenticity" for discussion's sake, which means people migrating from bitcoin feel they are in an authentic environment) is extremely important IMO and should be navigated consciously rather than unconsciously.
Take Bitshares or NxT for example. They've got the total "distinct" route. A user is in no doubt that they are in a non-bitcoin environment. The clients are nothing like QT. That's a good thing IMO. Dash needs to beware of falling in to the crevice between the authentic vs alternative world and stake it's identity out firmly.
Sorry for the rant - just had to get that off my chest
Have a nice day !
Good post Tok. Anyone that's been responsible for user interfaces (and the 'updating' of them) over so many years will have a particular set of experiences at just how risky it is introducing new features and functions in the belief it will be beneficial, but can often result in an adverse response from users. The Windows 8.1 'Metro' interface is probably a good example, with it's removal of the Windows Start button and the introduction of the wretched Charms bar and other finger swiping mechanisms that make no sense on a regular PC, it was universally hated (yet one can see what Microsoft was attempting to do from a mobile computing angle).
I agree with what you're saying about needing to carefully think whether we're aligning ourselves with the Bitcoin QT wallet and the ethos surrounding its development, use and the now extensive knowledge of what that concept represents or whether we're looking to differentiate ourselves completely onto an all new break-away concept for crypto 'money' that presents something quite different.
This goes right back to re-establishing clearly in mind what the design goals of Dash are, who the target market users are (and since we moved to the name Dash I'm not certain we're all that clear about that) and what human challenge, or need for improvement, Dash addresses.
I remember many years ago in the mid nineties when I worked for a Seattle based software company that had a very successful terminal emulation product, the company founder who also headed up the design team steered the product into all new channels to take advantage of the new 32 bit Windows environment that had just come onto the scene with Win95. He had this higher overarching view on creating more sophisticated ways of interrogating a mainframe's database and built-in to the product this quite advanced query tool that allowed a user to extract information with customised views and ability to build automated queries that could easily populate spreadsheets and other applications. At the time it was very whiz bang and we took it to our customers who were very excited, until....
About 6 weeks after this new version was released and all these customers had upgraded, we started fielding dozens of calls and emails per day from existing users saying "where's the file transfer facility?" The previous version had this very simple file transfer interface not dissimilar to PuTTY - PC on the left hand side, host system on the right with a button in the middle that had an arrow you could toggle left or right depending on whether you wanted to download a file from the host system or send it up. It worked like a charm but had no ability to customise a query and alter what information populated which fields. But that query customisation was a capability that our design team thought was where the product needed to go and they put an enormous amount of effort into its design. But existing users had little interest in it because for all but maybe 2% it was entirely outside the paradigm of how they interacted with their mainframe systems. What the development team failed to do though was, not only provide an orderly or understandable migration pathway/road-map, but completely misunderstand how their product was being used out in the field. Pretty soon customers were screaming at us as many of them had other software packages that used an API into our product to kick-off the file transfer as a minor component in a much larger process. It was a nightmare and I'll never forget it as a case of developers having a "purest ideology" mindset with no comprehension of what was important to the current user-base and the need for gradual change and expectation management. In the end they had to rush out an add-on 32 bit module of this classic file transfer facility but it took a month or two and we lost some customers in the process as they simply couldn't use the upgraded product and couldn't go back the old either.
Sooo....before making changes to our wallet, it's incredibly important to establish (or re-iterate because I know a fair bit of this is already well honed):
What are the design goals of Dash?
Who and what sort of person makes up the target market?
Does alignment to the Bitcoin 'standard' (if it can be described that way) meet the requirements of those first two points?
Or does the user interface need to be quite different?
A simple change like an additional passcode over and above the encrypted wallet passcode that we (in this community who've been around for a while) think is perfectly rational could end up being a "what the hell...!?" moment for users because we haven't considered it properly.
