Initially I was planning to respond with this in one of the GUI criticism topics, but it grew pretty large, so I decided it deserves a separate forum thread. So in response of my post I would like to see your thoughts on "fundamental issue” I mentioned below as well as your questions about our future plans and your ideas and suggestions. (Please note, that when you say “NXT/Crypti/you-name-it-wallet is better/cleaner” or Poloniex exchange is better - it’s not really helpful). I think most helpful UX feedback comes in the following form: “As <experienced (or not experienced) forex trader> (or <paypal user>, etc) I do <some operation> very frequently so if would be very helpful you put <this data> at <the bottom>; or you put <this button> on <top of the page>; or you remove <something> because it bloats UI”.

I think the most fundamental issue is that half of the community would like to see BitShares GUI as exchange, the other half as cryptocurrency wallet with built-in exchange. And in general - there is no consensus on what BitShares is.

While we were planning the GUI we decided to try to satisfy both points of view and build reference wallet that would be easy to customize, so the exchanges would turn it into exchange UIs, wallet service providers into a simple wallet suitable for general public.
The idea behind BitShares 2.0 was to create "platform" and provide some basic infrastructure, like blockchain, close to real-time API, reference wallet, referral program and let third parties build and monetize their own solutions built on this platform.
Another goal for the BitShares 2.0 GUI was to have all the functionality of 0.x wallet, so the current users wouldn't feel 2.0 as downgrade. Even if 2.0 GUI may feel not accomplished but it serves both goals well - it gives you a taste of Graphene capabilities and performance and also it's far superior to 0.x wallet.

And we are not going to stop here - there are big plans: the help system is under heavy development, just take a look at Membership page to have some idea - we are planning to add detailed help content to almost every page, also there will be "app tour" for new users. React native mobile GUI for iOS and Android should be out in a couple of months, all the backend and keys management are already in place; more gateways support is on the way; most of the blockchain features like proposed transactions; blinded transfers; privatized bit assets - all these are planned to be implemented before the end of year. The architecture we’ve chosen for 2.0 GUI has proven itself to be very effective and we are really getting up to speed (remember on one of the mumble sessions BM said this is the future of web development), and take a look at number of commits to graphene-ui repo - it's close to 2k already - twice as much as toolkit has got being longer under development.

And all these despite the fact that core developers were struggling for months to feed their families due to BTS price decline and dev fund melt down; and the idea to give up and return back to real-world salaries looked very attractive, btw community support was very helpful during that time, so I want to thank all you guys for staying here, even those with negative feedback, if you are still on the forum and you are testing software - this means that you still believe in BitShares and this really gives us the hope.

Я считаю нам нужен руско-язычный маркетинговый делегат со следующими обязанностями:
- публикация статей (например перевод блога BM) на популярных ресурсах типа Хабра
- создание сайта на русском и поддержка документации в актуальном состоянии
- агитировать биржи/обменники начать принимать BitUSD, BitRUB, BitGOLD
- возможно позже заниматься реферальными программами

Что думаете? Возможно найдутся желающие на эту должность?   
Зарплата делегата сейчас небольшая, зато есть возможность существенно увеличить себе зарплату своим трудом, например 10 млн долларов инвестированных в BitUSD должны увеличить капитализацию BTS в два раза, соотвественно вырастет и зарплата, причем чем больше рост BTS, тем больше проценты по BitUSD и BitUSD становится гороздо более привлекателен чем наличный доллар.

If we allow third-party applications inside BitShares client/wallet, a lot of things that require centralized services would be much easier to implement and make user friendly . Some examples:
- whoever runs a gateway (RealBTC<->IOUBTC) could publish an application, so users interested in this gateway could install an application be able to convert BTC to IOUs not leaving the client.
- faucet can run referral program, so users could use its application to redeem referral program's coupons or generate new coupons to share with friends right inside the BitShares client.
- escrow agent can have its own application specific to the service it provides.
- and many others more simple use cases, like advanced block explorers, market charts, and a lot more.

Another advantage - this allows us make the client as light as possible, by default it would contain only basic wallet functionality needed to register account and transfer funds, everything needed for more advanced users can be installed as applications, for example market GUI can be an extra app.

Later when ethereum-like scripting language is implemented, the same applications infrastructure could be used to interact with blockchain DAPPs.

And some technical details how this can be implemented.
A trusted party is needed to make this possible, first of all there should be some repository of applications, second, applications would have access to private keys, so there is a big security issue. I suggest delegates to be this party responsible for apps: delegates publish their list of trusted applications, the same way delegates now publish price feeds and toolkit version. List of applications can be publish json format, each application entry can contain download URL, API URL (if app is supposed to communicate with centralized service), checksum and the version number (if version changed the client will automatically update the application).
Technically, an application is Angular.js module - just a package comprised of html and js files. BitShares client downloads it, verifies checksum and signatures and plugs it in as Angular module.
There might be different rules for different kinds of application, e.g. if application doesn't require access to wallet_* rpc calls, it may require only one delegate to publish it, applications that require access to wallet_ calls may be required 10 or more delegates to publish feeds. To revoke an application, delegates just need to stop publishing it - BitShares client will mark it as revoked in the applications repository. DPOS shines again giving BitShares a huge advantage over competing platforms.

High-level description:
We can have marketing delegates that run faucet and finance referral program out of their payroll. The referral program pays some amount of BitAsset to identified unique users that download BitShares client and create account. For instance delegate can spend 80% of the payroll to fund referral program and pay 10 BitUSD per user/account created.
There would be also an initiative for users to invite their friends, e.g. each user referred a friend can get additional 10 BitUSD if friend installs client software and registers account.

The faucet would work as described below:
1. Somebody visits faucet website
2. There would be a clear call to action (CTA) “Download BitShares client, register account and get 10 BitUSD”.
3. Visitor clicks CTA link a goes over proof of person/identity verification process.
4a. After finishing step 3 visitor is suggested to download the client and install it.
4b. Also visitor gets a ’10 BitUSD coupon’ to his email address.
5. User installs BitShares client and clicks on a coupon link or just copies coupon code as text.
6. BitShares client/wallet opens coupon redemption page suggesting user to choose his/her account name and enter coupon code (if coupon linked clicked the coupon would be inserted automatically).
7. After user submits account name, BitShares client communicates with faucet website checking the coupon's validity, if coupon valid the faucet registers user’s account and credits it with 10 BitUSD.
8. Faucet generates new coupon, passes it back to client and client suggests user to share it with friends on Facebook, Twitter, forums, etc, if friend registers account, user gets 10 BitUSD and also friend going over identification process (steps #1-#7) gets his 10 BitUSD.

Advantages of this kind of referral program are:
- It's simple in terms of UX - user just goes over proof of person process, downloads and installs BitShares client, redeems coupon and chooses an account name, account name gets registered immediately.
- It's easy to implement - this doesn't require any toolkit changes or hard forks.
- It's self-sustaining - delegates compete to run the faucet - so stake holders voting for delegates, vote for some parameters of the campaign, such as niche served, marketing message, price per acquisition, so if stake holders think the dilution caused by the campaign not worse the value that new users bring it, stake holders vote out the delegate.
- This kind of campaign creates scarcity - spending 80% allows each delegate to register no more than 200 users each month within the current market cap, if there would be more users willing to register an account, the faucet can put them on a waiting list. Having a waiting list makes BitShares looks like something scarce which is good factor for successful marketing campaign, also this process resembles “invitations only” campaigns that were proven to be very successful (think gmail).

Implementation.
1. We need open source faucet/proof of person software that anybody can download and run as a website.
2. This software should be able to generate coupons and have json api, so BitShares client/wallet would be able to communicate with faucet.
3. Faucet software should be able issue and redeem coupons.
4. BitShares client/wallet should be able to communicate (via JSONP AJAX) with faucet to check and redeem coupons and making faucet to register user’s account.
5. Delegates running this service have to make all the records public so the community can audit referral links, coupons generated, etc and vote out non-effective delegates.

In order to BitShares client to find which faucet it needs to talk to redeem a coupon, delegates running faucets needs to publish faucet endpoint urls.
In general delegates can run not only faucet software, but provide some other services, so they can publish a list of services, e.g.:

"services": [
        {
            "name": "faucet",
            "version": "1.0",
            "coupon-prefix": "A123", // this is need for client to figure out what faucet to user to redeem coupon
            "url": "http://delegate-faucet.com/api/faucet/1.0"
        },
        {
            "name": "exchange",
            "version": "1.0",
            "url": "http://delegate-faucet.com/api/exchange/1.0",
            "app": {
                "url": "http://github.com/somedelegate/exchangeapp",
                "version": "0.1.2",
                "checksum": "1232142343243242"
            }
        },
        {
            "name": "escrow",
            "version": "1.0",
            "url": "http://delegate-faucet.com/api/escrow/1.0"
        }
    ]
Some of the services can be supported by the client out of the box like faucet or escrow service, some of them may require installation of angular module - delegates publish github link and client downloads and installs it, when delegates update app's version, client will automatically update it. If delegates removes this application from a list of provided services, client can uninstall the application. When delegate is voted out, the application would be no longer available.

Probably it’s too early to run full scale campaigns before we have stable network, simple lightweight client and on/off ramp services, but we before we get there we try this on a smaller scale, let’s have a single delegate running this and watch the results, if this would work, I'm sure stake holders would vote in more delegates running referral programs like this for different niches. Also voting in/out delegates may help us to figure out how much we want to pay for user acquisition and how much delegates can collect as compensation.

UPDATE 2
To prevent delegates from cheating and to have a single delegate efficiency metric (KPI) I suggest to remember first used faucet name or id somewhere in on the client/wallet side and make it to pass it to some centralized location each time the client is started, we can have a http callback address on bitshares.org for this, all the data gathered should be made pulicly available so everybody can see how many users opened the client multiple times and what faucets or referral programs have aquired those users.
Probably instead of a centralized location, we can find a way for clients to pass this data to all delegates on chain or off chain.

UPDATE 3
Some more features can be implemented on top of this, e.g. sending BitUSD to any email address directly from the wallet. Faucet operator just needs to have BitShares account so all the transfers to this account that include email address in the memo field would be forwarded to specified email address. There is no need for sender to create faucet account. Receiver needs to login to faucet via OAuth and verify email address.

UPDATE 4
This approach doesn't require a delegate position. It only requires a faucet with some funds that would be used to pay up referrals, it can be as low as 0.5BTS per user - just amount needed to register an account. Having a delegate running this kind of campaign just makes things simple.