Maybe I’m not forming the question well because I got nothing useful using search for some reason. Sorry if this is common knowledge that I’m not aware of. I don’t wish to multiply menus or menu types. I want the blog seamlessly integrated so as to appear a natural part of the Discourse experience.
I would like a Permalink next to the About that would reveal the WordPress Blog in Discourse clothing. Some hack that pulls the automagically generated WP Pages and populates a submenu like that of the About.
Make some provision for WP Catagories, and Tags? And Discourse entirely replacing WordPress Comments on Posts. The WordPress Admin would remain the same.
One other related design issue is my intention to create a multi-step registration using a WP Forms plugin. Again I don’t want anyone aware they are in WP, and later when logging in or out I was to lock the login to either just Discourse or just WP and hide the other login not in use.
We strongly recommend against this type of heavy use of iframes. They are intended for ephemeral snippets of content, nothing more. You’ll get into SEO issues and all sorts of other problems if you abuse iframes like this.
For visual cohesion you are much better off re-styling your Discourse navigation to match that of your WordPress blog: Brand Header
Not to play out the threadbare “Argumentative,” i.e., Angry Black Woman trope (again), but define “heavy-handed”? Would this require more than a single iFrame? If this is a sin then why, or is this like the church where I my questions are far from appreciated and I get answers that are uninformative criticisms?
Since proactive SEO tuning has zero currency in our application, can move on to point me at the Discourse Man. section that expands in detail on “abuse” of iFrames? I am problem-oriented, so if and when, a technical inhibition restricts the employ of sound design principles, I am more accustomed to addressing that as an engineering challenge.
Complexity beyond utility. I didn’t toss my proposal out for comment without research and deliberation. Introducing a second navigation tool to accommodate the ‘temporary’ use of WordPress and then replicating that model to other Federation community sites is not a road I intend to go down.
I need a solution that does not depart from the clean simplicity of the Discourse UI/UX design.
I have a user perspective on this. Unless I have misunderstood what you are trying to do, I expect that I would hate to have to use what you are proposing.
Any blog that I find useful will always entice me to follow the trails to other useful material (blog posts or links) and then I will find stuff that I want to share with others. The iFrame solution is only really suitable for small “snippets” that I will never want to navigate from or link to.
I lose too much basic functionality and utility every time a developer has the “great” idea of putting a website in an iFrame. It is usually done for expediency while discounting the impact on the user experience.
I appreciate that you are trying to be helpful. However, a single person’s anecdotal experience doesn’t contradict hard data on how people experience and use interfaces.
Trying to make the case that adding a second menu that behaves differently in form but essentially is accomplishing the same task to address a page that visually should not appear any different than the “About” is not a design logic you want to champion.
make that two, or consider me as not anecdotal because my opinion is based on documentation. Even if you work out CORS issues, there’s more to consider
… Because each embedded browsing content created by <iframe> is itself a complete document environment, every use of <iframe> within a page can cause substantial increases in the amount of memory and other computing resources required by the document overall … you should keep the potential for performance issues in mind. …
Accessibility concerns
People navigating with the aid of assistive technology such as a screen reader can use the value of a title attribute declared on an iframe to determine what embedded content it contains. … Without this description, they may have to navigate into the iframe and browse around to determine what the embedded content is. This context shifting can be a confusing and time-consuming process …
IMHO as long as there is unifying header navigation, common color palette, common fonts, you don’t need to strive for “identical looking” only “associated looking”.
In fact it could be argued that you are doing visitors a favor by having subtle differences. Just enough so they’ll know “I’m at the same site, but a different part of it, the UI will be this here”.
@Muiren, I feel your pain. You’re in trouble here for two reasons:
Reason 1: technical
From a UX perspective, separating a community web site from its discussion system is an aberration. In a bright future, web sites and discussion platforms will be accessible as components, which you can mix together to design an integrated experience. But we are far from this at the moment. Your web site is probably a monolithic pile of spaghetti code (did I hear Wordpress?) and Discourse is a monolithic platform.
You are suggesting using iframes to combine them. It is technically possible. In fact, lately, I have spent quite some time doing precisely this. But, like others have mentioned, it is very difficult, because iframes have not been designed for that purpose.
Reason 2: political
People here won’t help you with this. Possible reasons are:
They see no possible positive outcome (because of the technical challenge I’ve mentioned) and think it’s a waste of time.
They have “made a virtue of necessity” and will defend the monolithic approach.
Discourse is a commercial product whose source code is open. To charm “serious customers” despite the “open source” label, Discourse marketing strategy is to promote an “opiniated” approach. A direct consequence is that alternative use and experimentation are discouraged.
Non sono completamente d’accordo. Opinativo, sì; soffocante per la sperimentazione, no. Ci sono molte persone qui che sperimentano con Discourse in tutti i modi possibili (basta sfogliare la categoria Customization > Plugin!). È certo che il team di Discourse concentrerà il proprio lavoro su ciò che i clienti reali desiderano, ma non ho l’impressione che scoraggino la sperimentazione.
In questo caso, penso che sia più probabile questo:
Non è ancora emerso in questa discussione, ma vale la pena menzionarlo: esiste già un ottimo plugin per WordPress, WP Discourse, creato specificamente per collegare le due piattaforme. È utilizzato da molti, molti siti e ci sono già state molte ore di lavoro impiegate per far funzionare questo plugin, non solo per risolvere il SSO ma anche per altre funzionalità come:
Vedi:
Credo che la considerazione principale sia che nel 99,99% dei casi non ha senso reinventare la ruota (sia inserendo un intero sito WordPress in un iframe su Discourse, sia in altro modo) quando esiste già un ottimo modo per collegare le due piattaforme in modo più robusto tramite questo plugin e il SSO.
Certamente potrebbe essere tecnicamente possibile farlo in un altro modo, ma ciò che Erlend intende sottolineare è che esistono già soluzioni molto più semplici, ben consolidate e collaudate da molti siti. Adottare un approccio completamente diverso significherebbe dedicare molto tempo alla creazione di una soluzione personalizzata, con benefici non particolarmente evidenti.
Se qualcuno non ha ancora un sito WordPress consolidato o semplicemente non vuole occuparsi della configurazione dell’integrazione tra più piattaforme, un’altra possibile opzione sarebbe utilizzare direttamente Discourse per svolgere la funzione di piattaforma di blogging. Le persone l’hanno sicuramente provato e ne hanno discusso su Meta; un esempio qui: How to enable your community to use Discourse as a (micro) blogging platform
@Muiren You are welcome to use Discourse as you like – @erlend_sh was simply giving you advice. We do that if we think someone is making a mistake because we want all Discourse communities to succeed if possible. I agree with his advice.
@jack2 Your take is a little strange and completely incorrect. We define our product roadmap based on common feature requests. Feature requests from our hosted customers get more priority but they don’t change the roadmap in any other way.
Our intervention isn’t required here. You are welcome to hack your own Discourse instances in any way you see fit. Note that if we have advised against it, we won’t support you to fix it when it breaks.
